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PREFACE 


This  document  is  one  Qi  a series  describing  an  experimental  message  service  being 
developed  for  the  Advanced  Research  Projects  Agency  of  the  Department  of  Defense, 
part  of  a larger  effort  directed  at  the  problems  of  the  military  message  processing 
community.  The  goal  of  this  larger  effort  is  to  design  and  prove  the  efficacy  of  a 
system  for  automated  message  handling.  This  document  should  provide  the  basis  for 
discussion  and  refinement  of  the  concept  with  representatives  of  several  military 
message  environments. 

The  message  service  described  herein  has  been  designed  to  be  part  of  a new 
military  command  and  control  capability.  This  work  is  a fresh  look  at  these  problems, 
independent  of  the  constraints  of  current  command  and  control  systems,  although 
interim  use  will  require  interfacing  to  existing  systems,  including  AUTODIN  and  the 
ARPANET  message  protocol. 

The  main  goal  of  this  document  is  to  describe  the  functional  capabilities  necessary 
to  support  military  message  processing  {details  of  implementation  are  addressed 
elsewhere,  and  are  considered  beyond  the  scope  of  this  description).  This  document  is 
not  directed  at  any  particular  military  service,  command,  or  office;  rather,  it  describes  a 
general  set  of  functions  which  can  be  pared  down  or  specialized  to  meet  the  needs  of  a 
particular  environment. 

An  operational  interactive  message  service  needs  many  capabilities  and  amenities  In 
addition  to  the  basic  functional  capabilities  discussed  below.  These  include 
macro-commands,  synonyms,  abbreviations,  conferencing,  screen  control  and  peripheral 
I/O,  and  on-line  assistance  and  tutorials.  These  will  be  discussed  in  succeeding  Service 
Specification  Documents.  This  document  does  not  intend  to  address  any  of  these  user 
presentation  issues,  which  are  aggregated  as  the  "user  interface"  or  "user’s  agent."  In 
fact,  all  examples,  vocabulary,  and  commands  used  herein  are  illustrative  examples  only, 
not  intended  as  serious  suggestions  relative  to  user  interaction  protocols. 

In  several  places  throughout  this  document,  references  are  made  to  features  to  be 
implemented  in  a more  advanced  service.  The  service  described  within  represents  a 
base  from  which  more  sophisticated  and  powerful  services  may  be  designed.  It  is 
expected  that,  as  users  become  more  familiar  with  an  automated  service,  they  will 
likewise  become  more  knowledgeable  about  their  needs.  This  feedback  can  be  used  to 
incorporate  new  features  which  better  serve  the  user  community. 


1.  INTRODUCTION 


Since  A Plan  for  Consolidation  and  Automation  of  Military  Toloeommunicationt  on 
Oahu*  was  written  in  the  spring  of  1973,  !SI  has  been  examining  military  message 
processing.  This  has  led  us  to  the  conclusion  that  current  ARPANET  services  will  not 
properly  serve  this  user  community  for  two  reasons:  the  military  has  a very  formal 
structure  for  'record  communications'  which  is  not  reflected  in  current  ARPANET 
message  processing  services,  and  the  current  services  are  not  suited  to  the 
computer -naive  military  users. 

This  document  is  divided  into  three  introductory  sections,  followed  by  the  actual 
functional  specifications.  Because  the  area  is  quite  complex,  we  ask  your  patience  if  all 
terms  are  not  defined  immediately  and  simultaneously.  The  introductory  sections  are: 
1)  a short  description  of  current  military  operations,  2)  a brief  overview  of  an 
automated  service,  and  3)  definitions  of  the  primitive  d3ta  items  manipulated  by  the 
message  service. 

The  summary  of  current  military  record  communication  (Section  2)  briefly  outlines 
the  flow  of  message  traffic  through  a typical  military  installation.  In  Section  3,  the  flow 
of  a hypothetical  formal  message  is  traced  through  the  automated  message  service. 
These  two  sections  illustrate  that  the  automated  service  provides  all  the  facilities 
required  to  support  military  message  processing  while  serving  to  motivate  the  enhanced 
capabilities  supported  by  the  automated  service. 

The  remaining  sections  deal  with  the  specifications  of  the  automated  service’s 
functional  capabilities.  Section  4 defines  the  basic  items  of  data  manipulated  by  the 
service.  These  items  describe  the  contents  of  the  various  fields  of  a message  (which  is 
itself  described  as  a data  item).  Section  5 then  describes  the  functions  of  the  message 
service,  divided  into  three  categories:  preparation  phases,  post-preparation  phases,  and 
administrative  functions. 

Section  6 on  preparation  phases  attempts  to  capture  the  essence  of  the  complex 
interactions  between  the  users  involved  by  describing  them  along  two  dimensions, 
temporal  and  individual.  Some  redundancy  in  description  is  employed  to  allow  the 
reader  to  gain  insight  into  these  interrelations.  The  various  capabilities  and  facilities  of 
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1 CURRENT  MILITARY  RECORD  COMMUNICATION  SUMMARY 


Current  military  message  processing  embodies  three  important  considerations:  to 
provide  protocols  to  ensure  thnt  relevant  personnel  are  informed  of  pertinent  message 
traffic;  to  allow  officers  to  delegate  responsibility  to  subordinates  without  losing  control 
Or  accountability;  to  provide  the  means  by  which  messages  may  be  categorized  (by  such 
criteria  as  priority  and  special  handling  information)  and  treated  specially  when  the 
situation  warrants.  Al>  of  these  global  considerations  are  required  to  provide  smooth 
operation.  In  order  to  meet  these  goals,  each  message  goes  through  six  distinct  phases: 

1.  CREATION 

The  appropriate  'action  officer"  (decision  making  official)  is  assigned  the  action  on  a 
particular  subject  which  requires  a response  from  his  organization.  He  draws  up  a 
draft  of  an  appropriate  response. 

2.  COORDINATION 

The  action  officer  now  "coordinates"  (staffs)  the  response  with  the  other 
appropriate  action  officers,  which  both  maintains  the  integrity  of  the  organization 
position  on  this  subject  and  guarantees  the  completeness  of  the  response.  In  this 
phase,  other  action  officers  signify  accord  by  "chopping"  (signing)  the  draft  copy 
which  is  filed  in  the  action  officer’s  files. 

3.  RELEASING 

When  the  response  is  complete,  the  action  officer  acquires  the  appropriate 
signatures  to  release  the  response.  This  often  includes  some  of  the  coordination 
signers,  hut  always  includes  the  "releasing  authority"  (formal  sender  of  the 
message).  However,  the  releasing  authority  signature  may  be  signed  by  an 
appropriate  action  officer.  To  paraphrase  one  of  the  CINCPAC*  action  officers: 
"You  don't  resubmit  it  to  the  CINC,  saying  *Ptease  sign  again,  I made  the  changes  you 
told  me  to." 

This  example  demonstrates  that  the  procedures  are  not  ri^id,  and  can  be  bent  for 
expediency.  The  service  assumes  that  all  users  will  behave  honorably  with  respect 
to  their  delegated  authority,  and  trust  is  implicit,  though  audit  trails  maintain 
accountability.  The  service  below  has  many  of  the  same  flexibilities. 


e Comm#nde;’-in-Chief,  Pacific 
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4 ROUTING 

TN*  routing  process  performs  two  tasks.  Outgoing  routing  int«rrrj»C8S  with 
AUTOOlNa  and  provides  the  proper  AlfTOOlN  addresses.  Incomirg  routing  attempts 
to  provide  copies  to  all  appropriate  action  officers.  This  includes  reading  oart  cf 
the  message  for  key  words. 

5.  READ  BOARDS 

On  the  basis  of  the  incoming  routing  and  sender-sjrocified  security  and  priority, 
"reed  boards*  (folders  for  received  messages)  are  put  together  for  the  action 
officers.  Examples  include  routine,  secret,  information]  (cognition])  boards  and 
flash  top  secret  action  boards.  Info  boards  are  for  information  only  and  ar  j usually 
very  thick  and  widely  circulated.  Action  boards  are  particular  to  each  action 
officer. 

6.  ARCHIVE 

All  record  communication  is  maintained  by  the  communications  center  for  about 
three  years.  Individual  action  officers  might  keep  copies  longer. 


• Automatic  Data  Information  Network. 
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3.  OVERVIEW  OF  AUTOMATED  MILITARY  MESSACE  SERVICE 


The  remainder  cf  this  document  describes  the  rew  Automated  Military  Message 
Servic*.  Before  desc-ibing  the  functional  aspects  of  the  message  service  in  detail,  t is 
instructive  to  follow  the  path  of  a sample  formal  message  from  inception  through 
eventual  archival.  This  will  illustrate  the  types  of  operations  >r,d  transitions  whi.h  the 
message  fields  (i.e,  logir*'  sub-parts)  typically  undergo.  It  is  not  intended  to  Jefine 
critical  path  relations.  Note  that  several  terms  are  introduced  in  this  Overview;  they 
will  be  defined  in  succeeding  sections. 

Geatfon 

At  the  t.me  a user  states  his  desire  to  create  a message,  the  service  establishes  a 
unique  Creation  Identifier  for  tn.t  message.  The  service  expects  the  user  to  supply 
values  for  required  fields.  It  provides  applicable  default  values  for  those  fields  which 
ere  necessary  at  creation  but  which  the  user  has  not  specified  explicitly. 

The  author  now  supplies  the  fields  relevant  to  the  message.  These  include  a body, 
probably  one  or  more  recipients,  perhaps  some  preface  comments  to  the  coordinators 
and  reference  citations.  As  this  message  is  a formal  one,  he  will  also  supply  a releasing 
authority  list  and  probably  a coordination  list.  He  may  examine  and  modi*'/  anv  of  the 
fields  until  he  is  sufficiently  satisfied  with  the  message  and  ready  to  submit  it  for 
coordination. 

Coordination 

When  a message  enters  the  coordination  phase,  the  service  routes  the  massage  to 
the  coordinators  in  either  an  author-specified  nr  cocrdinator-direued  order.  Each 
coordinator  may  examine  the  message  and  the  previous  coordinators*  comments, 
suggested  changes,  and  th-*  dispositions  (such  as  OK,  NoGood).  He  may  also  suggest 
revisions  of  his  own  (to  tne  body  nr  coordination  list,  for  example),  add  comments,  and 
finally  g've  his  own  disposition. 

When  all  active  coordinators  furnish  their  present  review  of  the  message,  the 
service  notifies  the  author.  At  any  time  during  this  phase,  the  author  may  examine  the 
status  Of  the  message,  learn  which  coordinators  have  reviewed  it,  what  comments  and 
proposed  changes  they  have  made,  and  decide  which  changes,  if  any,  to  incorporate  into 
the  message.  The  message  continues  to  be  coordinated  until  the  author  is  satisfied  with 
its  progress.  At  that  point  he  marks  it  for  release. 
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Rtleat* 

When  a message  is  to  be  released,  the  release  list  becomes  active.  Each  of  the 
releasing  authorities  sees  the  message,  and  may  inspect  any  of  the  fields,  especially  the 
dispositions  given  by  the  coordinators.  Each  releasing  authority  may  also  comment  on 
the  message  and  decide  wheiher  or  not  he  wishes  it  to  be  released.  If  net,  he  may 
return  the  message  to  the  author  with  comments.  He  may  ask  thit  the  message  be 
again  coordinated,  or  perhaps  just  revised  to  be  resubmitted  for  release.  If  not  all  the 
releasing  authorities  approve  the  message  (either  personally  or  by  proxy),  it  is  returned 
to  the  author  with  their  comments,  it  is  then  the  author's  responsibility  to  modify  the 
message  so  as  to  gam  approval  from  all  release  authorities.  This  may  require  the 
author  to  resubmit  the  message  for  coordination.  Thus,  the  author-modification, 
coordination,  release  cycle  may  iterate  several  times  before  the  message  f*ams  final 
approval  by  all  necessary  authorities.  After  this  occurs,  the  message  is  read/  to  be 
transmitted. 

Trantmiition 

The  service  will  not  allow  a message  to  be  transmitted  unless  all  releasing 
authorities  have  given  an  OK  signoff.  If  so,  routing  to  destination  addresses  begins. 

The  service  establishes  » message-sending  protocol  with  each  of  the  destination 
sites.  This  protocol  would  include  specifications  of  all  necessary  transmission 
parameters,  and  positive  acknowledgment  of  message  reception  by  each  site  for  each 
recipient.  If  positive  acknowledgment  is  not  received,  the  origin  site  can  either  retry  or 
queue  the  message  for  later  transmission.  Such  decisions  would  be  made  on  the  basis 
of  message  priority  and  special  handling  criteria,  as  would  the  order  of  transmission  to 
recipients.  At  this  time,  the  service  also  consigns  the  final  version  of  all  formal 
messages  to  the  permanent  message  archive.  In  the  archive  Only  the  Identifiers  can  be 
used  to  identify  and  thus  access  a message.  Once  the  message  is  retrieved  *rcm  the 
archive,  the  other  fields  can  be  examined. 

in  a more  advanced  service,  there  will  be  an  on-line  file  containing  citations  for 
archived  messages.  This  will  allow  users  to  access  messages  by  their  subject,  recipient 
lists,  and  priority.  Citations  might  also  include  the  f rst  paragraph  of  the  message  for 
content  searches. 
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Delivery 

The  delivery  phase  is  marked  at  a particular  destination  site  by  the  establishment  of 
an  origin-destination  message  transmission  protocol.  The  destination  site,  once  having 
positive  delivery  of  a message,  signals  acknowledgment  to  the  origin.  Once  the  entire 
protocol  has  been  completed,  the  destination  site  processes  the  message  for  incoming 
routing.  The  receiving  service  places  just  the  message's  Transmission  Identifier  in  its 
permanent  archive,  as  a record  that  the  delivery  has  taken  place. 

If  the  message  contains  a specific  addressee  (person),  the  service  routes  the 
message  to  the  incoming  message  folder  of  the  appropriate  addressee.  If  the  recipient 
is  more  general  (e.g.,  an  organization  or  title),  the  service  searches  appropriate  message 
fields  (Subject,  Body)  for  keywords,  and  consults  routing  tables  to  determine  which 
User-IO  is  specified  to  receive  the  message.  Should  no  user  be  specifically  designated 
to  receive  the  message  with  such  content,  or  if  no  match  is  found  in  the  content  search, 
then  the  service  routes  the  message  to  a default  destination.  Here  a human  screening 
(based  on  installation-dependent  criteria)  will  determine  the  ultimate  destination.  Once 
the  message  has  reached  its  designated  recipient,  the  delivery  phase  is  finished. 

Reception 

The  r.»<-»ion  phase  begins  when  the  user’s  incoming  messages  are  scanned. 
Particular  attention  is  given  to  the  following  fields:  Type:  From;  Action,  Information  or 
Distribution;  Subject;  Body;  Priority;  Security.  Assignment  of  the  message  to  a 
particular  "message  folder"  is  made  by  pre-specified  receiver  personal  requirements. 
When  the  user  requests  a particular  folder  he  is  wtified  of  receipt  of  the  message, 
along  with  any  others  received  since  his  last  such  request.  The  user  can  then  view  the 
messages  in  any  message  folder  belonging  to  him.  He  may  see  entire  messages,  or  only 
specified  fields.  Also,  he  may  retrieve  cited  references  and  query  the  status  of  the 
message  relative  to  other  recipients.  He  can  specify  context  or  content  searching  on 
any  or  all  ► •rts  of  the  message.  He  can  then  also  decide  on  a disposition  for  the 
message:  delete,  assign  to  a record  file,  redistribute  to  other  interested  parties  (if 
allowed  by  special  handling  field),  produce  a hardcopy  version,  etc.  The  service 
I records  the  status  of  tha  message  for  each  recipient.  It  is  reported  to  special  file, 
which  can  be  queried  to  determine  the  global  status  of  any  message. 

i 

Archival 

The  archival  phase  is  not,  strictly  speaking,  a phase,  but  rather  represents  the 
permanent  record  of  all  formal  traffic.  Messages  may  be  archived  on-  or  off-line;  they 
are  not  accessible  except  by  a Message  Identifier  (discussed  below).  In  order  to 
examine  a message  in  the  archive,  a user  must  be  authorized  to  retrieve  a copy,  a 
privilege  granted  by  some  archive  authority  established  at  the  installatioa  Once  a user 
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retrieves  a message  copy  from  the  archive,  he  may  read  any  of  its  fields.  However,  he 
may  r>ot  redistribute  it  unless  permitted  by  the  archive  authority.  When  a user  is 
finished  with  his  copy  of  an  archived  message,  the  copy  is  destroyed. 
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4,  AUTOMATED  MILITARY  MESSACE  SERVICE  DEFINITIONS 


A mossage  is  a collection  of  message  fields,  each  of  which  contains  information  of  a 
particular  type.  The  contents  of  alt  of  these  message  fields  are  defined  in  this  section. 
Each  field,  at  one  time  or  another,  is  processed  by  the  message  service.  The  definitions 
4'#  divided  into  two  groups:  the  primitive  definitions,  and  the  compound  definitions, 
which  are  composed  from  the  primitive  types.  A message  is  an  example  of  a compound 
definition. 

PRIMITIVE  DEFINITIONS 

There  are  twelve  primitive  definitions.  They  are: 

1)  Text  item 

2)  Date 

3)  Time 

4)  Name 

5)  Title 

6)  Organization 

7)  Priority 

8)  Security  Classification 

9)  Special  Handling 

10)  Message  Type 

11)  Signoff 

12)  Version  Number 

Text  /urn 

A text  item  is  a string  of  ASCII*  characters.  These  characters  are  grouped  into 
words  and  the  words  grouped  into  paragraphs.  In  more  advanced  services,  the  text 
items  would  also  contain  formatting  information.  This  message  processing  service  does 
have  limited  formatting  capability  (paragraphs  and  words)  that  can  be  overridden  in 
order  to  allow  user -formatted  tabular  information.  Except  in  a few  special  situations, 
the  text  is  uninterpreted  and  considered  to  be  free  of  service-intelligible  semantic 
content.  Hov/ever,  whenever  a user  can  view  a text  item,  he  can  activate  a context 


e American  Standard  Code  for  ..^formation  Interchange. 
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March  on  that  item.  Automatic  context  searches  are  used  by  the  incoming  routing 
routines  and  the  folder  placement  routines  associated  with  the  reception  phase. 

Example: 

This  is  an  example  of  a text  item.  It  contains  38  words  and  two  paragraphs.  It 
is  also  automatically  formatted  (justified)  by  the  service. 

The  user  could  search  this  text  item  for  the  possible  keywords  "paragraph"  and 
"automatic". 


Date 

A date  is  descriptor  for  a day.  The  output  format  is  standard  throughout  the 
service  (JAN  17,  1974).  Many  ir  it  forms  are  recognized  by  the  service.  The  forms 
can  be  divided  into  two  groups.  The  first  group  consists  of  variations  on  the  calendar 
date  (e.g.,  6/18/74,  18  June  1974,  Jun  18).  The  second  group  are  relative  dates  (e.g., 
tomorrow,  yesterday,  next  Tuesday).  A more  advanced  service  might  also  recognize 
Labor  Day  1976,  or  the  third  Tuesday  of  this  month. 

Time 

A time  is  a descriptor  for  a time  Of  day.  The  output  format  is  either  local  time  or 
Greenwich  time  (7:04:32  PST  or  16:04:32  GMT).  Approximate  times  are  available  in 
input  <e.g.,  morning,  afternoon).  Again,  as  with  date,  both  clock  time  (1150,  1:30  PM, 
noon)  and  relative  time  (two  hours  from  now,  45  minutes  ago)  are  permissible  input 
forms. 

/Varne 

A name  identifies  a particular  individual.  The  standard  output  is  the  user’s  message 
service  identification  name  together  with  his  organization  (see  below).  This  is  unique 
throughout  the  entire  message  service,  or  even  throughout  a network  of  many  services. 
The  service  knows  an  individual’s  full  name,  organization,  mailing  address,  rank,  and 
current  title(s).  In  order  to  identify  an  individual,  the  user  need  not  know  the  exact 
identification  used.  Any  sufficient  information  that  uniquely  identifies  the  user  (e.g., 
initials  and  organization)  is  adequate. 


Examples:  SMITH,  JONES,  GEORGE 
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Title 

A title  (position)  is  independent  of  particular  individuals.  At  any  particular  instant 
in  time  there  is  an  individual  associated  with  each  title  in  the  service.  Titles  represent 
an  alternate  way  to  address  people.  Titles  provide  continuity  and  make  it  unnecessary 
to  inform  everyone  of  all  changes  in  the  organizational  structure.  A particular 
individual  may  have  several  titles.  In  a more  advanced  message  processing  service, 
several  individuals  may  have  the  same  title  (such  as  the  Ad  Hoc  Committee). 

Examples:  CINC,  J6124,  Director  of  ARPA-IPTO 
Organixation 

An  organization  is  a logical  collection  of  message  service  subscribers,  such  as 
CINCPAC,  ARPA-IPTO.  An  organization  must  be  distinguished  from  two  other  terms, 
both  of  which  refer  to  computer  configurations:  host  and  site.  A host  is  a particular 
physical  processor,  while  a site  is  a collection  of  such  hosts  (although  perhaps  only  one) 
operating  as  a single  entity. 

A site  might  service  and  support  several  organizations,  although  an  organization 
must  be  serviced  by  only  one  site.  For  example,  each  base  on  Oahu  would  be  an 
organization,  while  Oahu,  after  consolidation,  would  be  served  by  one  site.  In  a more 
advanced  service,  the  incoming  routing  routines  at  a particular  organization  might  route 
messages  to  individuals  at  other  sites  who  are  logically  part  of  that  organization  and 
temporarily  or  permanently  stationed  elsewhere. 

Priority 

The  priority  is  the  degree  of  urgency  which  the  sender  associates  with  the  delivery 
of  a communication.  These  are  used  on  all  inter-user  interactions  in  the  message 
processing  service.  Included  in  these  interactions  are  coordination,  release, 
transmission,  and  reception.  These  priorities  determine  both  the  scheduling  of 
communication  resources  and  the  method  of  delivery  to  the  user.  These  descriptions 
are  discussed  in  more  detail  below;  the  priorities  are  listed  in  order  of  increasing 
transmission  priority. 
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Priorities: 


Routine 

Put  in  appropriate  routine 

input  folder 

Priority 

Put  in  appropriate  priority 

input  folder 

Immediate 

Interrupt  user  upon  recept 

Flash 

Interrupt  user;  if  user  not 

available  try  alternate  or 
on-duty  officer 


Flash  Override 


High-priority  Flash 


Security  Classification 

This  is  the  security  level  of  the  message.  The  nandling  procedures  nre  defined  by 
the  Defense  Communications  Agency  and  National  Security  Agency. 


The  levels  are: 

Unclassified,  Encrypt  For  Transmission  Only  (unclassified),  Confidential,  Secret, 
Top  Secret,  etc. 

The  current  technology  handles  only  unclassified  traffic.  However,  a 

non-NSA-approved  encryption  facility  is  available  for  purposes  of  privacy.  This  facility 
is  only  applicable  to  the  message  body;  it  also  will  severely  limit  the  effectiveness  of 
the  incoming  routing  routines,  as  the  encrypted  text  cannot  be  searched  for  Keywords. 
However,  it  is  only  expected  to  be  used  for  eyes-only  messages.  A more  advanced 
service  will  handle  a larger  class  of  security  levels. 

Special  Handling 

This  data  item  affects  how  the  message  is  handled  at  certain  points.  The 
information  it  provides  directs  the  service  in  treatment  of  particular  messages,  such  as 
limit  the  receivers’  capabilities.  Examples  include  eyes-only  (directive  to  incoming 
routing  routines),  and  no  forwarding  (directive  to  reception  routines). 
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J teuage  Type 

The  message  type  may  te  formal  or  informal.  A formal  message  is  a normal  military 
record  communication  and  is  archived  and  maintained  by  the  message  processing 
service.  An  informal  message  is  off-the-record  and  copies  are  guaranteed  not  to  bo 
maintained  by  the  service. 

A digression  on  informal i y.  There  is  a significant  difference  in  treatment  of  formal 
and  informal  messages  by  t ,e  service.  In  particular,  for  informal  messages,  formal 
release  procedures  are  not  required  (i.e.,  the  author  may  send  the  message  with  no 
further  approval),  while  a formal  message  must  be  approved  by  its  releasers  (formal 
sender  and  Release  list).  A pai  ticular  organization  might  also  wish  not  to  allow  formal 
messages  to  be  sent  without  +he  approval  of  at  least  one  of  a special  list  of  Release 
Authorities,  who  control  all  or  _oing  formal  message  traffic. 

In  addition,  there  are  tv.  further  criteria  which  control  message  release,  both  of 
which  are  outside  the  message  service  domain.  First,  anyone  who  releases  a message 
is  responsible  for  its  contents  and  coordination.  People  are  expected  to  exercise 
proper  judgment  before  releasing  a document.  Second,  on  reception,  the  releasing 
authority  is  on  the  message.  It  is  expected  that  a message  released  by  Captain  Smith 
to  Major  Jones  will  carry  less  weight  and  be  more  open  to  question  than  one  from 
General  Black  to  Major  Jones. 

The  service  endeavors  to  be  flexible  and  friendly.  Its  main  responsibility  is  to 
gua'rntee  accountability  for  formal  messages.  There  are  no  anonymous  messages,  end, 
to  that  extent,  th9  releaser  is  accountable  for  either  formal  or  informal  traffic. 

Signoff 

There  are  many  ways  for  a coordinator  or  releaser  to  signify  his  disposition  of  a 
message.  These  are  discussed  in  much  detail  below  under  coordination.  The 
possibilities  are  listed  here  with  brief  comme~f'. 
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OK 

Unconditional  approval 

OK? 

Conditional  approval  - generally  positive 

0K- 

Conditional  approval  - generally  negative 

XIP 

No  decision  - X (something)  in  progress 

Read 

No  comment 

Not  Read 

No  action  at  all. 

As  stated  before,  these  will  be  discussed  in  detail  below;  however,  it  is  important  to 
note  that  not  all  of  them  are  available  in  every  situation. 

Version  Number 

A version  number  is  used  to  allow  users  to  quickly  tell  whether  an  in-progress 
message  has  been  changed  since  they  last  looked  at  it.  There  is  no  version  number 
stored  with  the  archive  copy  of  the  message. 

The  version  number  is  composed  of  two  numbers  separated  by  a semicolon.  The 
first  (left)  number  is  the  major  version  number  and  is  automatically  changed  by  the 
service  each  time  the  author  modifies  the  message.  The  second  number  is  the  minor 
'•ersion  number  and  is  changed  whenever  editing  suggestions  are  mads  by  the 
coordinators. 

COMPOUND  DEFINITIONS 

The  compound  definitions  are  built  up  from  the  basic  definitions.  They  are  defined 
to  be  concatenations  of  the  basic  definitions.  The  * is  used  as  the  concatenation 
operator.  There  are  seven  compound  definitions: 

!>  User-ID 

2)  Reviewer 

3)  Address 

4)  Recipient 

5)  Date-Time 

6)  Message-ID 

7)  Message 
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Ut*r-ID 

Name*Organization  or  Title*Organization 

A User-ID  identifies  a unique  individual  within  the  service  or  services.  It  is 
desirable  to  allow  the  same  name  or  title  to  exist  in  different  organizations  (to  allow 
more  natural  name/title  conventions).  The  restriction  that  all  names  and  titles  ar» 
distinct  within  a single  organization  allows  the  pairs  llame*Organization  and 
Title*Organization  to  be  unique.  These  names  identify  individuals  and  are  used  to 
identify  parties  responsible  for  the  transmission  of  a message  (compare  with 
Address). 

Reviewer 

User-ID*Priority*Special  HandlingaSignoffaText  Item 

These  people  are  listed  on  the  coordination  list  and  release  list.  A reviewer 
specification  not  only  identifies  the  responsible  individual,  but  also  describes  how 
the  service  should  deliver  the  in-progress  message  to  him  for  his  action.  The 
current  service  only  allows  reviewers  with>n  the  sa:..e  organization.  A more 
advanced  message  processing  service  would  allow  reviewers  to  be  at  any 
organization  and/or  any  site.  Once  again  we  are  still  talking  about  indiv:duals,  and 
not  activating  the  incoming  routing  routines  (compare  with  Recipient  below). 

Tho  priority  and  special  handling  subfields  ailow  for  a different  priority  and  special 
handling  code  for  each  reviewer.  It  is  possible,  using  this  model,  to  design  a service 
which  has  one  priority  and/or  one  special  handling  code,  which  is  associated  with  an 
entire  list  of  reviewers,  or  with  all  reviewers.  The  same  considerations  are  also 
true  for  the  recipient  definitions  discussed  below. 

The  signoff  field  lets  the  coordinator  signify  agreement  or  disagreement  with  the 
message  in  its  current  state.  The  text  item  field  is  for  comments  back  to  the 
author;  these  comments  are  automatically  deleted  when  the  message  is  transmitted. 

Addrett 

User-ID  or  Organization 

An  address  is  the  target  for  a message.  It  may  be  an  individual,  in  which  case  the 
User-ID  is  used,  jr  it  may  be  an  organization,  in  which  case  the  incoming  routing 
routine  for  that  organization  would  examine  the  message  and  determine  which 
individuals  should  see  it. 
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Recipient 

Address*Priority*Specia'  Handling 

A recipient  specification  is  similar  to  a reviewer  specification  in  that  it  describes 
where  and  how  to  send  a communication.  It  is  more  flexible,  as  it  uses  an  address 
end  may  go  to  any  organization.  These  addresses  are  used  to  define  where  the 
message  is  actually  transmitted:  the  action  list,  information  list,  and  distribution  list. 

Date-Time 

DeteaTime 

The  Date-time  type  describes  a point  in  time.  It  is  output  on  either  local  time  or 
Greenwich  time.  Certain  inputs  will  allow  the  date  to  be  defaulted,  such  as  17 
hours  from  now.  Also,  the  date  is  adjusted  when  converting  between  local  time  and 
Greenwich  where  appropriate. 

Meuage-ID 

Organization»Date-Time*(Name  or  Title) 

A Message-ID  is  a unique  handle  on  a message.  The  service  assigns  one 
Message  ID  to  each  message  at  creation  and  another  at  transmission.  Both  the 
Creation  Identifier  and  Transmission  Identifier  may  be  used  to  reference  a message. 

Though  the  organization  and  date-time  uniquely  identify  the  message,  the  Author  is 
appended  to  the  Creation  Identifier  and  the  From  (primary  releasing  authority)  is 
appended  to  the  Transmission  Identifier.  If  the  user  wishes  to  access  a message 
and  does  not  Know  the  exact  identifier,  he  may  request  to  see  all  messages  from  a 
particular  User-ID  on,  say,  last  May  7th  or  3th. 

Message-IDs  are  also  used  to  identify  other  messages  within  a given  message. 
These  references  (as  shown  be'ow)  are  grouped  in  a specific  field  in  a message,  and 
serve  to  point  users  to  other  sources  of  information. 

Examples: 

CINCPAC/Jun  6,  1974-17:47:05  by  J6124 
ARPA-IPTO/Jul  7,  1974-11:13.08  from  KAHN 
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A message  is  a collection  of  fields,  each  of  which  is  composed  of  an  instantiation  of 
a bask  or  compound  data  item  as  defined  above,  and  represents  a unit  of  traffic 
through  the  message  processing  service.  Messages  might  be  formal  or  informal  as 
determined  by  the  message  type  field.  Only  Type,  From,  Author,  Body,  Security  and 
either  Action  or  Information  list  are  required  for  the  transmission  of  a message. 

In  Table  1 are  the  allowable  fielcs  for  a message,  along  with  the  name  of  the  data 
item  used  to  specify  to  field  and  the  cefault  value  for  the  field.  The  meanings  of  these 
fields  will  be  discussed  in  detail  below.  During  the  active  lifetime  of  any  message,  the 
various  fields  undergo  creation,  revision,  verificat:on,  and  inspection  by  both  the  user 
and  the  service.  In  fact,  the  various  phases  of  the  message  service  may  be 
characterized  by  which  fields  take  an  active  part  in  the  processing  of  that  phase.  Table 
2 below  is  an  attempt  to  display  the  status  of  the  fields  as  the  message  passes  from 
one  phase  to  the  next. 

The  ordering  of  the  phases  in  Table  2 is  relevant,  although  it  is  not  meant  to  imply 
strictly  one-way  serial  transition.  A message  may  pass  back  and  forth  several  times 
between  the  coordination  and  release  phases,  and  the  reception  and  archival  phases. 
However,  the  status  of  the  fielas  for  a particular  phase  is  independent  of  the  path 
through  which  a message  has  already  traveled 
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TABLE  1 

MESSAGE  FIELD  TYPES  AND  DEFAULTS 


E2EU2 

DATATYPE 

Type 

Message  type 

From 

Reviower 

Author 

User  *10 

Action  list 

Recipient(s) 

Information  list 

Recipient(s) 

Distribution  liat 

Recipient(s) 

Coordination  liat 

Reviewar(s) 

Release  list 

Reviewers) 

Preface  comments 

Text 

Subject 

Text 

Body 

Text 

Creation  identifier 

Message-10 

Transmission  identifier 

Message-fD 

Reference  list 

Mess  age-1  D(s) 

Security 

Security  classification 

DEFAULT  VALUE 
INFORMAL 

author  *ROLfTlNE*  null  *NOT -READ*  null 
[User-iD*Priority*Spec  handling*  Signoff  *Comment] 

Creating  uaaraCraatlng  aits 

null  aROUTINE*  null 

[Address*Priority*Spec.  handling] 

null  eROUTINE*  null 

[Address*Priority*Spec.  handling] 

Release  and  coordination  Hat 

null  *R0UT1NE*  null  *NOT-READ*  null 

[User-iD*PriorityeSpec  handling*  Signoff  eComment] 

null  *ROUTINE»  null  *NOT-READ*  null 
[User-ID*Priority*Sp9c  handling*  Signoff  *Comment] 

null 

null 

null 

{supplied  by  service  at  creation) 

(supplied  by  the  service  at  transmlaalon) 
null 

UNCLASSIFIED 


Version 


Version  number 


1(0  (maintained  by  service) 
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TABLE  2 

MESSAGE  FIELD  TRANSITIONS 


Creation 

Coord. 

Release 

Transmit 

Delivery 

Roception 

Archive 

Type 

P 

P 

P 

AF 

PF 

AF 

AF 

From 

P 

P 

P 

PF 

PF 

AF 

U 

Autnor 

A 

A 

A 

PF 

PF 

PF 

U 

Action  list 

P 

P 

P 

AF 

AF 

AF 

U 

Information  list 

P 

P 

P 

AF 

AF 

AF 

U 

Distribution  list 

P 

P 

P 

AF 

AF 

AF 

U 

Coordination 

P 

A 

P 

FF 

PF 

PF 

U 

Release  list 

P 

P 

A 

PF 

PF 

PF 

U 

Subject 

P 

P 

P 

PF 

AF 

AF 

U 

Preface  comment 

P 

P 

P 

X 

X 

X 

X 

Body 

P 

P 

P 

PF 

AF 

AF 

U 

Creation  ID 

AF 

AF 

AF 

AF 

AF 

AF 

AF 

Tranamitsion  ID 

X 

X 

X 

AF 

Ar" 

AF 

AF 

Reference  list 

A 

A 

A 

PF 

PF 

AF 

U 

Security 

A 

A 

A 

AF 

AF 

AF 

AF 

Version 

KEY: 

A 

A 

A 

X 

X 

X 

X 

P:  passive 

field  not  needed  by 
be  empty. 

?F:  passive  frozen 

service, 

but  open 

for  user 

examination  or  modification  - 

may 

field  open  for  examination,  but  not  modification 


A:  active 

field  must  be  nonempty  if  it  is  an  essential  one:  service  verifies  field  for 
completeness  end  authenticity;  stilt  open  for  modification 

AF:  ective  frozen 

contents  of  field  are  verified,  but  may  not  be  modified 

U:  unavailable 

field  cannot  be  accessed 

X;  nonexistent 

field  does  not  exist  during  this  phase. 


Preceding  psge  blank 
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5.  MILITARY  MESSAGE  SERVICE  FUNCTIONAL  SPECIFICATIONS 


The  proposed  message  service  can  be  logically  divided  into  two  parts.  The  first, 
celled  preparation,  is  concerned  with  the  creation  of  a message  and  the  feedback 
necessary  to  render  it  acceptable.  The  remainder,  called  post-preparation,  involves  the 
trmsmission  and  dissemination  of  completed  messages  to  their  intended  recipients. 

PREPARATION  PHASES 

During  the  preparation  phases  of  the  message  service  (creation,  coordination, 
release),  many  individuals  may  come  into  contact  with  a given  message,  for  purposes  cf 
composition,  transcription,  review,  modification,  comment,  or  approval.  These  users  will 
make  varied  demands  on  the  service  ana  will  be  provided  certain  types  of  access  and 
control  rights  to  messages.  This  section  enumerates  the  individuals  who  may  be 
involved  with  a message  during  the  preparation  phases  and  which  actions  appropriate 
to  preparation  are  allowed  each  participant. 

Dramatis  Personae 

The  people  who  come  into  contact  with  a message  during  the  preparation  phases 
fall  into  four  classes:  author,  advisor,  reader,  and  releaser  (the  latter  three  will 
collectively  be  referred  to  as  reviewers).  Briefly,  their  general  functions  during  the 
preparation  phases  are: 

AUTHOR 

The  author  is  the  primary  individual  responsible  for  the  creation  of  a message.  He 
has  totai  control  over  the  message  until  release. 

ADVISOR 

The  advisor  is  a coordinator  who  can  give  extensive  advice  to  the  author  through 
the  process  of  "editing"  suggestions  into  the  draft  message. 

READER 

The  reader  is  a restricted  coordinator  who  can  only  make  comments  on  the  draft 

message. 

RELEASER 

The  releaser  signs  off  the  message  and  by  his  authority  approves  the  message’s 
transmission. 
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The  author(s)  and  tha  designated  advisors,  raadars,  and  ralaasars  will  ba  referred 
to  as  ociart.  Each  of  these  actors,  whan  fulfilling  his  role  for  a particular  message,  may 
in  turn  select  a ghoit.  A ghost  wilt  normally  serve  transcription  purposes  (i.e.,  a 
secretary),  and  in  general  will  have  equivalent  capabilities  to  those  of  the  appointing 
actor,  in  effect,  the  rights  to  act  on  a given  message  (hereafter  referred  to  as  domain ) 
assigned  to  a user  (actor)  may  be  transferred  to  a substitute,  although  the  actor  may 
decide  to  discharge  his  function  personally.  However,  an  actor’s  domain  may  be  in  the 
hands  of  only  one  user  at  a time,  thus,  there  must  be  only  one  ghost  allowed  any 
actor  on  a given  message;  should  the  actor,  after  assigning  the  domain  to  a ghost,  wish 
to  act  personally  on  the  message  or  assign  it  to  another  ghost,  he  must  first  reacquire 
the  rights  to  the  message  (which  is  always  allowed).  The  use  of  ghosts  is  not  recorded 
with  the  transmitted  or  archived  copies  of  a message,  and  the  interaction  between 
actors  and  ghosts  is  assumed  to  be  outside  the  message  service. 

Chott*.  The  assignment  of  ghosts  can  be  set  up  within  the  service  in  a large 
number  of  ways.  However,  when  capabilities  are  assigned  to  a ghost,  the  ghost’s 
actions  remain  the  direct  responsibility  of  the  user  whose  name  the  ghost  is  using. 
Ghost  assignment  can  be  restricted  to  just  the  coordination  or  creation  of  a single 
message,  through  receiving  incoming  traffic,  up  to  and  including  all  message  service 
interactions.  This  last  item  is  equivalent  to  giving  the  ghost  the  actor’s  password  and 
terminal. 

This  document  mostly  addresses  the  issues  of  one-shot,  single-  assignment  ghosts. 
In  these  cases,  the  actor  informs  the  service  of  which  of  his  capabilities  he  wish  to 
transfer  to  whom.  This  might  be  "allow  Miss  Jones  to  coordinate  message  XYZ  and  then 
stgn  off  with  an  OK." 

However,  several  more  permanent,  less  restrictive  ghost  assignments  could  be  made 
possible  within  the  message  processing  service.  The  user  could  assign  all  incoming 
traffic  of  a certain  type  to  be  delegated  to  a certain  ghost.  For  example,  an  action 
officer  might  specify  that  all  routine  messages  be  assigned  to  his  secretary  for 
preliminary  screening.  It  is  worth  mentioning  that  the  routing  algorithm  will  dp  this  in 
art  official  recorded  way,  such  that  not  only  the  work  is  moved,  but  also  the 
responsibility.  A ghost  is  dbuigned  to  be  an  assistant  and  not  a co-worker.  Another 
possible  ghost  assignment  would  be  to  allow  the  ghost  all  rights  except  signoff.  The 
possibilities  for  ghost  assignmenl  are  very  large,  and  it  will  require  discussions  with 
specific  end-users  to  resolve  how  they  would  use  this  feature  of  the  service.  This  is 
also  true  because  ghost  assignment  has  more  to  do  with  interactions  with  the  su 
staff  than  with  the  message  service. 
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During  the  preparation  phases,  there  is  a complex  set  of  interactions  involving  the 
phase  in  profress,  the  roles  of  the  users  (author,  advisor,  etc.),  and  the  range  of 
capabilities  available  during  preparation.  To  best  illustrate  these  interdependencies 
without  introducing  too  much  circularity  in  description,  the  preparation  phases  will  be 
discussed  along  two  different  dimensions:  available  capabilities  and  user 

characterizations.  While  duplicating  some  information,  this  method  of  presentation 
allows  the  most  ins'ght  into  the  nature  of  the  conduct  of  the  preparation  phases. 

Available  Capabilities 

Each  of  the  users  who  comes  into  contact  with  a draft  message  has  certain 
capabilities  with  respect  to  that  message.  Following  is  a list  of  all  capabilities  relevant 
to  a message;  the  next  section  discusses  the  subset  of  these  capabilities  allowed  each 
actor. 

Vieu.  Viewing  is  the  ability  to  inspect  all  message  fields,  and  is  granted  all  sctors 
and  ghosts.  While  viewing,  the  user  has  the  ability  to  see  all  previous  comments  and 
edits  (hereafter  called  annotations)  incorporated  into  the  message  fields  (either  marked 
to  delimit  changes  or  unmarked);  with  or  without  identification  of  the  users  who  made 
them.  In  viewing,  the  user  may  choose  in  which  manner  he  wishes  to  view  the  various 
annotations,  and  the  service  will  provide  reasonable  defaults  for  those  left  unspecified. 
There  are  five  classes  of  annotations.  They  are  listed  below  with  their  associated 
viewing  options. 

General  Comments 

These  are  contained  in  the  comment  text  item  cubfields  of  each  reviewer 
entry. 

OPTIONS: 

Show*  (authors’  default) 

Don’t  Show  (reviewers’  default) 

In-Field  Comments 

These  comments  are  within  any  message  field.  They  can  only  be  created  by 
advisors  and  authors.  1 

OPTIONS: 

Show  (authors’  default) 

Don’t  Show  (advisors’  default) 

Show  and  Identify  Advisor(s) 

Additions 

These  are  additions  to  any  message  field.  Again,  only  advisors  and  authors 
can  do  this. 
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OPTIONS: 

Show  (reviewers’  default) 

Show  Marked  (authors*  default) 

Show  Marked  and  Identify  Advisor(s) 

Deletions 

Similiar  to  additions. 

OPTIONS: 

Don’t  Show  (reviewers'  default) 

Show  Marked  (authors’  default) 

Show  Marked  and  Identify  Advisor(s) 

Replace 

These  are  paired  additions  and  deletions.  Again,  only  advisors  and  authors 
might  make  these  annotations. 

OPTIONS: 

Show  New  Version  (reviewers’  default) 

Show  Both  Marked  (authors’  default) 

Show  Both  Marked  and  Identify  Advisor 

Readers  and  releasers  can  only  make  general  comments.  The  i ^viewers’  viewing 
default  is  to  see  the  current  state  of  the  message.  The  authors’  default  is  to  see  all 
changes.  This  is  to  enable  and  encourage  the  suinor  to  pass  judgment  on  the 
suggested  changes  which  only  the  author  can  do. 

Edit.  Editing  is  the  process  wherein  a user  (author  or  advisor)  proposes  changes 
to  a draft  message.  The  user  may  add  to  or  delete  from  message  fields,  or  he  may 
replace  sections  of  fields  with  new  information.  In  making  his  changes,  he  has  access  to 
ell  the  changes  and  comments  made  by  the  previous  reviewers.  All  the  viewing  options 
are  available  during  editing  to  facilitate  making  changes.  The  editing  history  of  the 
message  is  thus  available.  Each  time  a coordinator  edits  a message  the  minor  version  is 
incremented  by  one. 

It  is  important  to  note  that  none  of  the  changes  made  during  editing  are  actually 
made  to  the  original  message.  The  service  records  the  changes  made  during  each  edit, 
and  they  are  incorporated  during  later  viewings  or  editings  to  show  the  message  as 
currently  modified.  Actual  changing  of  the  message  is  accomplished  during  a process 
called  "modify"  which  is  described  below.  Thus,  the  changes  made  during  editing  serve 
as  suggestions  to  the  author,  who  may  incorporate  editing  changes  or  not,  at  his 
choosing. 
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Th«  actual  interactive  dialogue  used  to  evoke  the  edit  functions  will  be  compatible 
with  the  Editor's  general  format.  A discussion  of  this  format  is  beyond  the  scope  of 
this  document. 

Modify.  The  author  of  a message,  after  having  reviewed  the  annotations  by 
coordinators  and  releasers,  may  wish  to  update  the  message  to  reflect  the  comments 
and  suggested  changes  he  has  received.  This  process,  called  modification,  is  reserved 
entirely  for  the  author  (or  autho.  ’s  ghost).  The  author  may  employ  any  of  the  viewing 
options  to  display  the  message  and  annotations,  and  may  modify  any  of  the  fields  with 
the  exception  of  the  various  reviewers'  signoffs.  Once  he  has  made  modifications,  the 
message  exists  as  the  new,  updated  version,  and  future  views  or  edits  of  the  message 
will  *f.p\y  to  the  modified  version.  Each  time  the  author  modifies  the  message  the 
major  version  number  is  incremented  by  one  and  the  minor  version  number  is  set  to 
zero. 

In  making  modifications,  the  author  may  be  guided  by  the  suggested  edits  and 
comments  of  the  reviewers,  and  may  in  fact  decide  to  update  the  message  by 
incorporating  the  edits  as  specified  by  the  advisors.  He  is  not,  however,  bound  to  heed 
any  of  the  suggestions,  as  the  author  alone  is  responsible  for  the  content  of  the 
message  during  preparation.  Failure  to  incorporate  suggested  changes  (or  making 
changes  other  than  those  suggested)  may  have  effects  on  the  signoff  given  by 
reviewers,  and  this  will  be  discussed  under  the  section  on  signoff,  below. 

Mettage  State  Control.  While  a message  is  in  the  preparatory  phases,  it  is 
undergoing  review  and  modification  by  a potent  illy  large  group  of  users.  Each  of 
these  users  has  some  amount  of  control  over  the  disposition  of  the  message,  depending 
upon  his  role  in  the  preparation  process. 

The  service  allows  the  author  total  control  over  the  message  at  all  times.  He 
decides  when  a message  is  to  be  distributed  for  advising,  reading,  and  release,  and  may 
recall  the  message  during  any  stage  of  those  processes.  For  example,  the  author  may 
send  a message  out  for  reading,  and  be  informed  that  an  urgent  situation  requires 
immediate  release.  He  can  rescind  the  reading  order,  possibly  interrupting  readers  in 
progress,  and  route  the  message  to  the  release  authorities  immediately.  The  control 
capabilities  granted  the  author  are  also  assignable  to  an  author  ghost. 

The  service  additionally  allows  indivioual  reviewers  control  capabilities  only  with 
respect  to  their  designated  ghosts.  That  is,  once  a reviewer  has  actively  begun 
discharging  his  function  for  a message,  and  assigns  his  domain  to  a ghost,  he  may 
revoke  that  domain  at  any  time  and  handle  the  message  personally,  or  assign  it  to 
another  ghost.  A realistic  example  might  occur  if  an  advisor  assigned  a secretary  to 
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•nter  • lengthy  list  of  changes  and  comments  to  a draft  message,  and  the  secretary  was 
later  required  to  perform  another,  more  pressing  task.  The  advisor,  upon  learning  this, 
could  remove  the  message  from  the  secretary's  task  list  and  reassign  the  duties  to  a 
substitute. 

Commant.  It  is  often  helpful  to  accompany  a document  with  a set  of  general  or 
specific  comments  (none  of  which  is  permanently  recorded)  which  are  more  informal 
than  edits  and  can  possibly  provide  more  insight  into  the  reviewers'  perceptions  of  the 
document.  The  message  service  will  support  an  extensive  repertoire  of  commenting 
facilities,  designed  to  provide  the  users  in  the  preparatory  phases  with  as  much 
feedback  capability  as  possible. 

For  the  author,  who  writes  the  draft  message,  comments  would  be  most  useful  as 
preface  comments,  which  could  give  a more  general  explanation  of  the  author's  aims,  or 
perhaps  to  point  out  parts  of  the  message  worthy  of  special  attention.  These  preface 
comments  are  directed  to  the  reviewers  and,  as  with  all  comments,  are  not  part  of  the 
final  message. 

Advisors  are  permitted  to  comment  anywhere  in  the  message.  This  allows  them  to 
explain  reasons  for  proposed  changes,  or  discuss  why  a prior  change  is  incorrect  or 
inappropriate.  They  may  also  make  general  comments  which  apply  to  the  message  as  a 
whole. 

Readers  and  releasers  are  allowed  to  make  general  comments  only.  The  reasons 
for  this  are  explained  in  the  sections  dealing  with  readers  and  releasers  below. 

While  reading  a message,  a user  has  the  capability  to  see  the  author’s  preface 
comments,  and  normally  all  of  the  previous  reviewers’  comments.  For  reasons  of 
privacy,  the  service  does  allow  reviewers  to  make  private  comments,  viewable  by  the 
author  only.  Authors,  of  course,  can  see  all  comments,  and  delete  any  or  all  of  them  at 
will.  Once  a message  is  released,  all  comments  are  deleted,  and  are  never  recorded  !n 
the  permanent  message  archive. 

Si?noff.  A primary  function  of  reviewers  is  to  acknowledge  their  reading  of  a 
message,  and  maybe  an  overall  mark  indicating  their  relative  degree  of  concurrence  and 
approval.  The  message  service  allows  reviewers  a wiae  spectrum  of  marks  or 
"signoffs",  designed  to  provide  latitude  for  the  reviewers,  while  giving  the  author  and 
releasers  maximal  information  on  which  to  base  their  actions. 

Table  3 lists  the  available  signoff  codes,  the  reviewers  authorized  to  use  them,  any 
status  changes  the  codes  may  undergo  during  the  preparatory  phases,  and  the  final 
signoffs  as  recorded  in  the  archive. 
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TABLE  3* 

SIGNOFF  STATUS  CHART 


Signoff 

Coda 

Applicable 

Reviewor(s) 

Status  at  Release 

Becomes 

Archive 

Status 

If  Massage 

Same 

If  Message 
Changed 

OK 

Adv,Rdr,Rel 

OK  final  — 

OK  final 

OK  prelim  ™ > 

OK  prelim 

OK? 

Adv.Rdr 

OK  final  — 

OK  final 

Read  prelim  -> 

Read  prelim 

OK- 

Adv,Rdr,Rel 

CK  final  — 

OK  final 

NG  prelim  — > 

NG  prelim 

Read 

Adv.Rdr 

Read  final  ~ 

Read  final 

Read  prelim  -> 

Read  prelim 

NG 

Adv,Rdr,Ral 

NG  final  — 

NG  final 

NG  prelim  — > 

NG  prelim 

Not  read 

Adv,Rdr 

Not  read 

Not  read > 

Entry  deleted 

CIP.GCIP 

Adv,Rdr 

CIP.GCIP 

CIP.GCIP > 

Entry  deleted 

RIP, GRIP 

Ral 

RIP, GRIP 

RIP, GRIP > 

Message  not 

transmitted 

* See  key  to  Table  3 on  the  following  pages 
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KEY: 

Applicable  reviewers 

Reviewers  who  may  use  this  signoff  coda  (Adv«advisor,  Rdr-reader,  Rel-releaser) 

Status  at  release 

A reviewer’s  signoff  may  be  altered  depending  on  whether  the  message  has 
changed  since  he  signed  it  off.  The  two  columns  under  “Status  at  release"  ("if 
message  same,"  "if  message  changed")  represent  the  possible  transformation  of  a 
signoff  for  particular  situations.  In  this  case,  "changed"  means  the  message  does 
not  exist  exactly  as  it  did  when  the  reviewer  signed  it  off,  including  his  changes. 
This  could  be  because  the  author  did  not  incorporate  the  reviewer’s  (and  previous 
reviewers’)  suggested  changes,  the  author  incorporated  changes  made  by 
succeeding  reviewers,  or  the  author  made  changes  of  his  own. 

final,  prelim 

Service-generated  status  which  records  whether  or  not  the  signoff  made  by  a 
reviewer  refers  to  the  final  message  (i.e.,  the  message  has  not  been  further 
modified,  in  the  sense  above),  or  a preliminary  version  (i.e.,  the  message  has  since 
been  modified).  Note  that  changes  in  comments  or  signoffs  do  not  constitute  a 
change  to  the  message. 

Signoff  Codes. 

OK  Reviewer  is  satisfied  with  message,  even  if  modified.  Reviewer  does 

not  wish  to  review  message  again  unless  substantial  changes  are  made.  The 
service  will  not  change  this  signoff  status  if  the  message  is  changed. 

OK?  Reviewer  is  generally  satisfied  with  message  but  only  if  it  does  not 

further  change  after  his  signoff.  Would  probably  want  to  see  message  again  if 
changed  further.  If  the  message  is  changed  in  any  way,  the  service  will  change 
the  signoff  to  a Read  signoff. 

OK-  Reviewer  is  generally  unsatisfied  with  message,  but  will  accept  only  if 

indicated  changes  are  made.  Would  definitely  want  tc  see  message  again  if  it 
were  further  changed.  If  the  message  is  changed  in  any  way,  the  service  will 
change  this  signoff  to  NoGood. 

Read  Reviewer  has  read  message,  but  is  generally  uncommitted  in  his  opinion. 

Would  probably  not  want  to  see  message  again.  If  the  message  is  changed,  this 
signoff  will  stay  intact. 
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NG  NoGood.  Reviewer  disapproves  of  message,  because  either  he 

fundamentally  disagrees  with  it  or  believes  it  to  need  extensive  revision  to 
become  acceptable  {comment  to  determine  which).  Wishes  to  see  message  again 
if  he  believes  revision  'e6ded.  Only  the  reviewer  can  change  this  signoff. 

Not  Read  Reviewer  has  not  yet  had  a chance  to  review  message. 

CIP  Coordination-in-progress,  Reviewer  has  begun 

GCIP  Ghost  coordination-in-progress  review,  but  has  not  yet  finished. 

Wishes  to  finish  review. 

RIP  Release-in-progress,  releaser  has  begun  review,  but 

GRIP  Ghost  release-in-progress,  has  not  yet  finished.  Wishes  to  finish 

review. 

This  service  allows  conditional  signoffs  (OK?,  0K-).  Note  that  these  conditional 
signoffs  are  transitory  only,  they  never  appear  in  the  final  version  of  a message.  Their 
transmutation  to  non-OK  signoffs  depends  on  whether  or  not  the  message  is  modified 
after  they  are  made.  This  includes  any  changes  to  the  text  of  the  message  or  any  of 
the  message  fields.  Changes  to  comments  or  signoffs  are  not  considered.  [In  a more 
advanced  service,  there  might  be  other  types  of  conditional  signoffs,  such  as  "if  certain 
fields  don’t  change,"  or  “if  someone  else  signs."] 

Note  that  the  ‘not  read’  and  ‘coordination-in-progress’  signoffs  are  not  recorded  in 
the  archive,  nor  are  their  corresponding  reviewers.  The  ‘release-in-progress’  signoffs 
are  not  allowed  to  be  on  a transmitted  message,  as  explained  in  the  section  on 
releasors,  below.  Also  note  that  there  are  only  three  archive  signoffs:  OK,  NoGood,  and 
Read. 

Once  a reviewer  is  designated  by  the  author,  he  is  given  a default  ‘not  read’  signoff, 
which  will  remain  until  the  reviewer  explicitly  orders  it  to  be  changed.  Reviewers  may 
change  only  their  own  signoffs,  and  the  author  may  not  change  any. 

If  a reviewer  has  made  a signoff  which  indicates  he  wishes  to  see  the  message 
again,  it  is  up  to  the  author  to  route  the  message  bach  to  the  reviewer.  However,  the 
author  is  not  bound  to  do  so.  Clearly,  the  author  should  advise  a reviewer  if  the  author 
modifies  a message  to  the  point  where  it  no  longer  carries  the  same  meaning.  An 
example  would  be  when  a reviewer  signs  off  ‘OK’  (unconditional),  after  which  the  author 
modifies  the  message  so  that  it  no  longer  contains  the  same  substance  as  when  it  was 
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approved  While  the  author  should  be  obligated  to  send  the  message  bach  to  the 
reviewer,  enforcement  is  outside  the  scope  of  the  messagi  service.  However,  the 
automatic  changes  shown  in  the  signoff  chart  are  designed  to  protect  the  users. 

A digression  on  expedition.  Now  that  we’ve  defined  the  reader  and  advisor 
functions  and  also  the  signoff  codes,  it  is  proper  to  discuss  ways  to  expedite  messages 
through  the  service,  .n  a leisurely  transmission,  the  authors  might  send  a message  for 
advisor  coordination,  repeatedly  viewing  and  incorporating  suggestions  and  making 
compromises  until  all  the  coordinators  give  an  OK  signoff.  The  message  is  then  sent  tc 
the  releasers,  who  were  probably  all  coordinators,  for  an  easy  release,  and  finally  the 
From  person  gets  the  final  approved  message  for  final  transmission  signoff.  This 
process  can  be  quite  extravagant  in  the  use  of  elapsed  real-time. 

Several  mechanisms  are  provided  within  this  design  to  expedite  this  process,  nrst, 
the  preface  comment  field,  and  the  fact  that  the  author  may  specify  the  coordination 
order,  allows  the  transmission  of  off-the-record  comments  and  careful  ordering  to  affect 
the  behavior  of  recalcitrant  coordinators. 

Second,  the  edit  capabilities  of  an  advisor  both  encourage  the  advisors  to  be 
(possibly  overly)  thorough,  and  also  forces  the  process  to  be  sequential  (i.e.,  only  one 
advisor  may  edit  a message  at  a time).  For  these  reasons,  the  reader  coordination  was 
developed.  Readers  may  not  edit;  they  may  only  sign  off  and  make  comments  with  their 
signoff.  This  is  intended  to  force  the  comments  to  a more  global  level.  The  other 
pleasant  side-affect  is  that  many  readers  might  operate  in  parallel. 

The  signoffs  have  been  structured  to  reduce  the  number  of  times  a document  is 
seen  by  a reviewer.  The  OK  signoff  allows  the  reviewer  to  place  trust  in  the  author. 
He,  in  turn,  is  partially  protected  by  the  service,  which  records  whether  he  saw  the  final 
version  of  the  message.  The  in-progress  signoffs  allows  a reviewer  to  free  the 
document  for  another  reviewer  without  finishing  his  review. 

Finally,  the  Read  signoff  is  available  for  coordinators,  allowing  a noncommittal 
signoff.  In  many  cases  it  might  be  easier  to  get  a Read  than  OK.  It  should  be  noted 
that  transmission  depends  only  on  releasers,  not  coordinators.  It  is  assumed  that  the 
releasers  will  base  their  judgment,  in  part,  on  the  coordinators’  signoff.  Releasers 
might  release  a message  in  which  some  coordinators  have  given  Read  signoffs,  while 
they  would  not  if  those  signoffs  were  NoGoods. 

So,  by  using  all  these  features,  the  author  can  send  off-the-record  comments  to  a 
large  number  of  readers  in  parallel.  Using  the  Read  signoff,  they  can  review  quickly.  If 
this  signoff  is  accepted  by  the  releasing  authority,  a message  can  be  prepared  and 
coordinated  with  minimum  expenditure  of  real-time. 
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(/nr  Characterization*  During  Preparation 

This  rcction  attempts  to  delineate  the  functions  performed  by  the  various  users 
during  the  preparatory  phases.  It  will  explain  the  specific  duties,  options,  and 
capabilities  of  the  users,  and  describe  the  nature  of  the  interaction  between  them. 

Author.  The  author  is  the  central  figure  in  the  message  service.  He  has  final 
responsibility  (until  release)  of  the  draft  message  and  ultimate  control  of  the  message 
throughout  the  preparatory  phases.  He  decides  what  the  content  of  the  message  will 
be,  who  the  recipients  will  be,  and  who  will  serve  as  coordinators  and  release 
authorities.  Typically,  the  author  will  no'  be  equally  active  through  the  different 
preparatory  phases,  although  he  is  capable  of  taking  active  part  at  any  time. 

A digrettion  on  authority.  Until  a message  is  released  and  transmitted,  the  service 
recognizes  the  author  as  the  primary  source  of  true  information.  The  author  hac  total 
control  of  the  life,  and  possible  death,  of  the  in-progress  message.  At  this  point  the 
author  is  superior  to  the  designated  From  'primary  releasing  authority)  with  regard  to 
the  message. 

The  author  can  add  and  delete  coordinators  and  releasers  at  will.  He  can  delete 
any  reviewer  comment,  and  the  reviewers  themselves,  if  he  pleases.  In  fact  any  author 
can  put  himself  in  the  From  field  and  release  the  message.  The  service  recognizes  no 
control  over  the  author.  This  is  to  make  the  author’s  job  as  easy  and  flexible  as 
possible.  If  some  of  the  author  rights  seem  overly  powerful  or  arbitrary,  it  is  important 
to  realize  that  the  author  still  works  within  a structure  of  responsibility.  An 

irresponsible  author  will  be  chastised  outside  the  message  service  domain.  The 

flexibility  and  power  is  meant  to  be  wisely  used.  The  service  assumes  reasonable 
users,  i.e.,  users  who  will  not  anger  other  users. 

A message  may  have  several  authors  (each  of  whom  may  have  his  own  ghost).  At 
any  time  only  one  author  might  be  editing  or  modifying  the  message.  However,  this 
restriction  is  not  enough  to  prevent  the  authors  fr„m  working  at  cross-purposes.  No 
automatic  aids  have  been  designed  in  this  service  to  solve  this  problem.  Authors  are 
expected  to  work  out  areas  of  responsibility  among  themselves.  Any  of  the  authors 
might  request  notification  of  message  status  changes.  They  are  viewed  as  equals  by 
the  service.  The  currently  active  author  or  the  next  active  author  is  the  author  who  is 
relevant  to  most  of  the  discussion  below. 

The  range  of  actions  the  author  may  perform  depends  on  the  current  phase  of  the 
message.  The  applicable  author  functions  are  discussed  below  relative  to  the  various 
preparatory  phases. 


functional  specifications 


32 


CrMiioii  During  this  phase,  the  original  draft  of  a massage  is  prepared. 
Frequently  the  volume  of  information  to  be  entered  into  the  service  is  targe,  and  the 
author  may  wish  to  assign  a ghost  (ija.,  secretary)  to  perform  the  entry.  Since  this 
assignment  would  not  be  in  service-readable  format,  the  ghost  in  this  situation  would  be 
acting  with  no  service-checked  authority.  The  ghost  may  thus  prepare  any  draft 
message  without  formal  service  notification  of  the  eventual  author.  In  this  case,  the 
ghost  serves  as  the  primary  author  while  the  message  is  being  entered.  The 
ghost-author  (e  ghost,  acting  as  author  during  initial  entering  of  a message  into  the 
service)  is  listed  as  the  author  of  the  message  and  has  all  author  rights.  He  may  read 
or  modify  any  of  the  message  fields  (except  signoff),  and  may  initiate  or  terminate  any 
Of  the  other  preparatory  phases.  In  addition  to  entries  of  new  information,  the 
ghost-author  (or  real  authors)  may  incorporate  text  from  other  messages  or  files  into 
the  draft  message.  This  facility  will  be  especially  useful  when  several  authors  work  on 
different  parts  of  a message  in  parallel.  Once  the  ghost-author  has  finished  his  task,  he 
transfers  authorship  to  the  real  author  (as  specified  in  the  Author  field  of  the  message). 
This  transfer  gives  the  real  author  all  the  associated  control  capabilities,  until  and 
unless  he  subsequently  further  reassigns  authorship.  This  procedure  allows  secretaries 
to  create  messages  without  the  actual  author  becoming  involved  with  the  service  until 
necessary. 

The  transfer  of  author  status  to  the  real  author  allows  him  to  determine  the  further 
processing  of  the  message.  He  may  edit  or  modify  the  message,  initiate  advisor  or 
reader  coordination,  or  initiate  release.  He  may  also  assign  a ghost  any  of  these 
capabilities. 

It  is  important  to  note  here  that  the  various  reviewer  and  recipient  lists,  while 
established  during  the  creation  phase,  may  be  subsequently  modified  by  the  author  (or 
ghost)  as  he  feels  (or  is  advised)  appropriate.  The  service,  as  an  aid  to  the  author,  will 
immediately  notify  him  should  any  of  the  designated  reviewer  or  or  recipient  entries  be 
invalid,  and  defer  activation  of  a dependent  phase  (coordination,  release,  transmission) 
until  the  proper  corrections  are  made.  This  insures  that  the  service  will  not  have  to 
terminate  processing  because  it  encountered  invalid  addressee  specifications  while  in 
the  middle  of  a phase. 

To  expedite  the  preparation  of  repetitious  or  fixed-format  ("canned")  messages,  the 
service  will  also  provide  a facility  whereby  an  author  can  prepare  a template  of  a 
message,  possibly  with  certain  fields  left  unspecified,  which  can  be  completed  and 
transmitted  very  rapidly.  Sending  such  a message  would  involve  only  the  retrieval  of 
the  template,  filling  in  (and  possibly  slightly  altering)  any  necessary  information,  and 
marking  the  message  for  the  next  applicable  phase  (release,  coordination,  etc.). 
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Coordination.  The  author’s  involvement  in  the  coordination  phase  begins  by  his 
initiation  of  the  phase.  In  doing  so,  he  has  several  options.  He  must  first  decide 
whether  to  initiate  advisor  or  reader  coordination,  since  the  two  may  not  occur 
simultaneously,  as  explained  below  in  the  section  on  reviewers.  Should  the  author  wish 
to  specify  a particular  routing  order,  he  may  do  so.  He  may  activate  any  subset  of  the 
coordination  list  and  change  these  activations  at  will.  The  author  may  wish  to  initiate 
coordination  and  not  further  involve  himself  until  all  coordinators  have  finished.  By 
explicitly  marking  each  coordinator  as  an  advisor  or  reader,  the  service  will  route  the 
message  in  the  appropriate  way. 

At  any  time  during  coordination,  the  author  may  interrogate  or  modify  the  status  of 
the  message.  He  can  determine  which  coordinators  have  acted  upon  the  message,  and 
whether  any  coordinators  are  currently  working  on  it.  He  may  examine  the  nature  of 
their  edits  and  comments.  Should  he  deem  it  appropriate,  he  can  remove  the  message 
from  either  coordination  state  (advise,  read),  the  service  automatically  notifying  any 
coordinators  in  progress.  Or,  he  may  ask  the  service  to  alert  him  when  all  active 
coordinators  have  finished.  Once  having  retrieved  the  message,  he  may  modify  the 
coordination  list,  change  the  coordination  state,  or  terminate  coordination  entirely  and 
mark  the  message  for  release.  If,  after  processing  the  message  in  some  way,  the  author 
decides  to  resubmit  the  message  for  coordination,  he  may  choose  to  continue  at  the 
interrupted  point,  or  specify  some  different  routing. 

In  order  to  optimize  use  of  the  author’s  own  time,  he  may  request  the  service  to 
delegate  any  of  the  above  capabilities  to  a ghost,  who  may  then  execute  the  desired 
actions. 

Releaso.  The  author’s  options  during  the  release  phase  are  analogous  to  those 
during  coordination.  He  may  initiate  or  terminate  release,  modify  the  release  list  or 
other  message  fie'ds,  and  resubmit  the  message  to  coordination  and  release  phases.  In 
addition,  if  the  message  has  been  signed  off  acceptably  (OK)  by  ail  release  authorities, 
the  author  may  mark  the  message  to  be  transmitted. 

It  is  important  to  point  out  that  phase  or  state  changes  (e.g.,  between  rebase  and 
coordination,  or  between  advise  and  read)  do  not  alter  existing  signoffs.  Only 
modification  of  the  message  or  explicit  direction  of  the  individual  reviewers  affects 
signoff  changes. 

Transmission.  When  the  author  is  satisfied  with  the  progress  cf  a message,  he 
may  request  the  service  to  transmit  it.  The  service  immediately  notifies  the  author  if 
not  all  releasers’  signoffs  are  OK,  and  defers  transmission  until  such  is  the  case.  Once 
the  messago  has  been  accepted  for  transmission,  the  author  loses  control  of  the 
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message,  which  becomes  service  property.  AM  field*  are  dosed  to  further  modification, 
and  the  preparatory  phase  is  ended. 

fteefoiear*.  The  interaction  of  reviewers  with  a draft  message  is  more  limited  than 
that  of  the  author.  In  addition  to  having  fewer  capabilities  for  affecting  the  content  of 
a message,  they  have  less  direct  c sntrol  over  a message  even  when  tney  are  actively 
working  on  it. 

During  the  preparatory  phases,  the  reviewers  can  have  one  of  three  possible 
statuses:  inactive,  potentially  active,  and  active.  When  a reviewer  is  inactive,  either  the 
message  is  currently  in  a different  phase,  or  the  reviewer  has  already  completed  his 
work  on  the  message  ?n<j  signed  it  off.  Giving  an  in-progress  signoff  will  not  make  a 
reviewer  inactive. 

When  the  author  activates  a given  phase,  the  service  notifies  all  the  designated 
reviewers  that  they  have  been  made  potentially  active,  uxduding  those  users  who  have 
made  unconditional  OK  signoffs  indicating  they  do  not  need  to  see  tne  message  again. 
The  interaction  with  each  of  the  users  here  depends  on  l)  the  current  activity  of  that 
user,  2)  the  service  actions  the  user  has  chosen  regard  ng  pending  tasks,  and  3)  the 
priority  cf  the  message  relative  to  that  reviewer.  If  the  user  is  not  currently  logged 
on,  the  service  will  remen  ber,  and  notify  the  user  when  he  next  logs  in,  if  he  is  still 
potentially  active  at  that  time.  If  the  user  is  on  the  service,  the  action  taken  by  the 
service  depends  on  the  user’s  current  task,  and  the  priority  and  special  handling  fields 
of  the  message  designated  for  the  user.  A typical  set  of  default  service  actions  when  a 
user  is  made  potentially  active,  but  is  invn'ved  in  another  task,  based  on  message 
priority,  might  be: 


routine 

priority 

immediate 


notify  user  by  adding  message  to  user’s  task  list 

notify  user  by  adding  message  to  user's  priority  task  list 

interrupt  user  - he  may  process  message  immediately,  cr  defer  it,  in 
which  case  message  is  added  to  immediate  task  list 


flash  interrupt  user  unless  he  is  processing  a flash  message  now  - flesh 

messages  should  be  processed  before  other  business 

flash  override  interrupt  user  - he  must  process  the  message  before  returning  to 
any  other  tasks,  including  flash  messages. 
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Should  a uiar  not  act  upon  a message  at  his  first  opportunity,  he  will  remain 
potentially  ac’ive  (unless  the  author  changes  the  phase),  and  the  service  will  wait  for  a 
reviewer  to  request  access  to  the  message.  A reviewer,  when  finally  ready  to  process 
a message,  may  find  the  message  inaccessible.  This  could  be  caused  by  the  author's 
changing  the  phase  or  coordination  state  of  the  message,  making  the  reviewer  inactive, 
or  by  another  reviewer  actively  processing  the  message.  In  the  former  case,  the 

1 reviewer  will  be  informed  anew  should  the  author  reactivate  the  appropriate  phase.  In 

> the  latter  case,  the  reviewer  has  more  explicit  control.  He  can  instruct  the  service  to 

do  one  of  the  following: 

- Nothing.  The  user  will  explicitly  ask  later  about  the  status  of  the  message,  and 

request  access  if  free. 

I - Notify  the  user  when  the  message  is  available.  The  user  may  then  decide  whether 

I or  not  to  process  the  message  (a  reasonable  default). 

t 

- Gain  control  of  the  message  when  available,  and  interrupt  the  user  from  his  current 

I task. 

I 

Once  a reviewer  has  gained  access  to  a message,  he  is  considered  active.  He  will 
• remain  active  until  one  of  two  events  occur.  If  the  reviewer  signs  the  message  off,  he 

■ re'inquishes  control,  and  is  made  either  potentially  active  or  inactive,  depending  upon 

his  eignoff.  On  the  other  hand,  if  the  author  revokes  control  from  the  reviewer,  he  is 
made  potentially  active  Or  inactive  on  the  basis  Of  the  author's  succeeding  directions. 

It  is  now  appropriate  to  discuss  the  functions  and  capabilities  of  the  three  types  of 
reviewers:  advisors,  readers  and  releasers. 

A4vi$ort.  Advisors  are  provided  the  most  feedback  capability  of  the  reviewers. 
They  furnish  the  author  with  his  primary  source  of  suggestions  and  comments. 

A prospective  advisor  is  notified  of  his  role  at  the  time  he  is  m*de  potent  lily  active 
(by  the  author’s  activating  advise  coordination).  His  options  at  this  point  are  immediate 
action  on  the  message,  or  deferral  until  some  later  time.  Naturally,  his  decision  will  be 
affected  ty  the  message’s  priority  and  special  handling.  His  deferral  can  be  permanent 
(in  other  words,  never  acting  on  the  message).  In  such  a case,  if  the  message  reaches 
the  transmission  phase,  the  aovisor’s  User-IQ  will  be  deleted  from  the  coordination  list. 

When  an  advisor  wishes  to  act  on  messages,  he  may  first  query  his  task  list.  The 
service  maintains  lists  of  all  pending  tasks  for  each  user,  which  can  be  sorted  in  any 
user-specified  fashion.  Once  having  selected  a message,  the  advisor  notifies  the 
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service  of  his  intention  to  review  the  message.  Access  to  that  message  may  be  denied 
him,  as  described  in  the  previous  section,  so  he  might  proceed  by  choosing  another 
pending  message. 

Should  he  be  granted  access  to  a message,  all  other  reviewers  are  denied  access 
until  he  is  finished.  Whiie  he  has  access,  he  may  do  any  of  the  following: 

• View  the  message,  using  any  of  the  viewing  options.  He  may  see  any  edits  or 
comments  from  previous  reviewers. 

- Edit  the  message.  His  cnanges  will  be  recorded  and  available  to  all  succeeding 
reviewers  and  the  author. 

• Make  appropriate  comments  anywhere  within  the  message. 

- Sign  off  the  message  with  his  disposition.  (The  signoff  may  be  accompanied  by  a 
comment  as  well.) 

Any  signoff  except  CIP  (coordination-in-progress)  indicates  that  the  advisor  has 
finished  with  the  message  in  its  current  form.  CIP  is  useful  when  the  advisor  has  not 
finished  his  review,  but  must  stop  because  of  other  business.  By  signing  off  CIP,  the 
advisor  allows  other  reviewers  to  process  the  message. 

An  advisor  may  assign  transcription  of  his  annotations  to  a ghost.  The  ghost  then 
acts  as  the  advisor  in  all  ways  except  for  signoff.  The  advisor,  when  assigning  a 
message  to  a ghost,  has  the  following  options  regarding  signoff: 

• The  ghost  may  not  sign  off  for  advisor.  When  the  ghost  is  done,  he  returns  the 
message  . > the  advisor,  who  subsequently  signs  off. 

• The  ghost  may  sign  off  with  any  allowable  code. 

- The  ghost  must  sign  off  with  one  of  a specific  set  of  codes  (possibly  only  one). 

If  a ghost  must  interrupt  processing  of  a message,  he  may  sign  it  off  GCIP.  Any 
other  signoff  will  be  recorded  with  the  message  as  if  the  advisor  signed  off,  possibly 
constrained  by  the  third  option  above. 

At  any  time  during  ghost  processing,  the  advisor  may  reacquire  the  message  (force 
a GCIP  signoff)  and  either  continue  processing  personally  or  reassign  it  to  another 
ghost 
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Readers.  There  are  many  occasions  during  message  preparation  when  detailed 
comments  and  changes  by  reviewers  are  either  unnecessary  or  undesirable.  For 
example,  an  author  might  find  further  edits  i)  unnecessary  once  he  has  received  enough 
suggestions  to  correct  any  deficiencies  in  the  draft  message  or  2)  undesirable  if  speedy 
processing  through  the  remainder  of  the  coordination  list  is  essential.  he  message 
service  provides  for  such  situations  by  the  reader  coordination  mode. 

In  general,  a reader  has  the  same  capabilities  as  an  advisor,  with  the  exception  of 
editing  and  detailed  comments  (per  message  field).  These  limitations  provide  several 
useful  effects.  Since  the  readers  may  not  make  detailed  annotations,  they  may  review 
the  message  more  quickly,  knowing  that  only  their  general  impressions  are  needed. 
Also  recall  that  the  author  activates  readers  and  advisors  separately,  so  that  the  two 
groups  are  never  potentially  active  at  the  same  time.  This,  coupled  with  the  fact  that 
readers  are  not  permitted  to  edit  the  message,  allows  more  than  one  reader  to  review 
the  message  simultaneously.  Thus,  the  use  of  readers  during  the  coordination  phase 
can  greatly  expedite  processing  of  a draft  message. 

Readers  have  the  same  options  regarding  ghosts  and  signoffs  as  advisors.  In  the 
final  version  of  a message,  readers  are  not  distinguished  from  advisors. 

During  the  coordination  phase,  additional  lemporary  additions  to  coordination  list 
entries  exist,  identifying  the  statuses  of  readers  and  advisors.  The  possible  statuses 

are: 

AR  active  reader  (currently  processing  message) 

PR  potentially  active  reader 

IR  inactive  reader  - has  signed  off  (code  not  CIP  or  GCIP) 

AA  active  advisor 

PA  potentially  active  advisor 

IA  inactive  advisor  > has  signed  off 

I inactive  coordinator  - not  active  or  potentially  active 

At  release,  all  statuses  go  to  I (inactive).  This  field  disappears  at  message 
transmission. 
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Rtltauri.  While  the  author  of  a message  is  responsible  for  its  content,  the 
releasers  represent  the  authority  which  causes  a message  to  be  transmitted.  In 
particular,  the  user  identified  in  the  From  field  of  a message  is  a releaser,  in  addition  to 
any  other  users  specifically  entered  in  the  release  list.  No  message  may  be  transmitted 
unless  it  is  approved  (via  OK  signoffs)  by  all  releasors.  The  releaser  may  be  the 
author,  who  may  transmit  the  message  with  no  outside  approval.  However,  messages 
important  enough  to  require  the  mention  of  high  officials  as  being  in  accord  should 
include  those  officials  as  releasers.  This  insures  that  such  messages  must  be  approved 
by  all  relevant  authorities  before  transmission. 

It  is  possible  that  certain  user  groups  will  require  restrictions  on  the  users 
authorized  to  release  messages.  The  message  service  will  allow  enforcement  of  such 
restrictions,  so  that  all  transmitted  formal  messages  must  have  the  approval  of  one  or 
more  of  a specific  set  of  designated  authorities.  The  restrictions  would  be  involved 
with  transmission  only;  nonauthorized  users  could  still  create  and  coordinate  formal 
messages. 

Releasers  have  capabilities  and  options  similar  to  readers.  When  the  release  phase 
is  activated  by  the  author,  releasers  are  notified  of  their  status.  Since  releasers  may 
not  edit  a message,  several  raleasers  may  be  active  simultaneously.  If  any  releaser 
signs  off  a message  with  a code  other  than  OK,  the  author  is  notified,  and  transmission 
of  the  message  is  delayed  until  all  releasers  sign  off  with  OK. 

A releaser  may  appear  as  a coordinator.  If  so,  when  he  is  activated  as  a 
coordinator,  the  releaser  may,  when  signing  off,  notify  the  service  that  his  coordination 
signoff  will  serve  as  his  release  signoff  as  well.  This  may  obviate  the  need  to  re-route 
the  message  to  the  releaser  later.  Naturally,  if  a releaser  gives  a conditional  signoff 
(OK?,  0K-)  and  the  message  is  subsequently  changed,  the  releaser  must  see  the  message 
again  and  approve  it  before  it  can  be  transmitted. 

POST-PREPARATION  PHASES 

This  section  discusses  the  post-preparation  phases:  transmission,  delivery, 

reception,  and  archival. 

Trantmution 

The  transmission  phase  is  initiated  by  author  request.  The  service  immediately 
checks  the  message  for  approval  of  all  releasers,  and  notifies  the  author  if  there  are 
any  releasers  who  have  not  signed  off  with  OK.  If  so,  the  author  must  get  the 
necessary  approvals.  Otherwise,  the  message  is  readied  for  transmission. 
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Readying  a message  for  transmission  involves  assignment  of  a permanent 
Transmission  Identifier  (if  it  is  a formal  message),  removal  of  those  fields  necessary  only 
during  preparation  (e.g.  comments,  version  number),  deletion  of  the  User-ID’s  of 
coordinators  who  did  not  review  the  message,  and  finalization  of  all  signoffs 
(transforming  any  conditional  sigr-'ffs,  adding  ’final*  or  ’prelim’  to  signoffs  as 
appropriate).  Once  these  have  been  accomplished,  the  message  is  in  its  final  form,  and 
will  not  be  further  modified. 

At  this  point,  the  message  is  routed  to  its  destination  addressees.  It  is  not 
appropriate  in  this  document  to  be  any  more  specific  about  the  actual  transmission 
procedure  than  outlined  above  in  the  Overview,  but  an  additional  note  is  relevant 
regarding  the  proposed  service’s  interface  to  existing  message  services.  While  the 
model  proposed  is  assuming  a homogeneous  network  of  message  sites,  each  running  the 
service,  it  is  highly  unlikely  that  such  a situation  would  exist  in  practice.  The  service 
would  have  to  interface  to  other  message  services,  both  manual  and  automated.  While 
discussion  of  such  interfaces  is  beyond  the  scope  of  this  document,  any  more  detailed 
specifications  for  specific  user  groups  would  include  such  considerations. 

Delivery 

After  completion  of  the  message  transfer  protocol  between  two  sites,  the  delivery 
phase  begins.  Delivery  performs  all  the  incoming  routing  necessary  to  get  the  message 
to  the  proper  destination  and  provides  copies  to  various  additional  users  or  titles  as 
required. 

The  most  important  function  of  delivery  is  determining  the  appropriate  destination 
for  an  incoming  message.  The  service  provides  a flexible,  dynamic  means  of  providing 
•uch  routing,  by  means  of  routing  tables. 

Routing  tables  are  established  by  service  administrators  and  individual  users, 
through  an  interactive  dialogue  with  the  service.  During  this  dialogue,  the  administrator 
or  user  specifies  how  routing  is  to  take  place  under  foreseeable  circumstances,  and 
what  actions  are  to  be  taken  in  exceptional,  unforeseen  cases.  The  criteria  used  to 
determine  routing  would  probably  use  the  Priority,  Special  handling.  Subject  and  Body 
of  incoming  messages. 

The  priority  of  a message  would  normally  determine  the  service’s  insistence  on 
finding  an  on-line  user  as  the  destination.  Low  priority  messages  would  receive  little 
treatment  unless  specifically  requested  by  the  addressee.  High  priority  messages, 
however,  which  need  immediate  attention,  would  always  be  routed  to  an  active  user.  If 
the  desired  addressee  were  not  available,  the  service  would  first  try  any 
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addressee-specified  alternates,  and  ‘inally  a Known  active  user  (such  as  the  active  duty 
officer). 

The  existence  of  a special  han..  ing  field  would  probably  determine  the  allowable 
limits  of  forwarding.  For  example,  an  eyes-only  message  would  never  be  forwarded, 
regardless  of  priority.  Other  ty*.-''  of  special  handling  could  additionally  widen  or 
narrow  the  service's  forwarding  attempts. 

The  Subject  and  Body  fields,  where  the  content  of  a message  lies,  provide  keywords 
which  the  service  can  use  to  determine  routing.  The  service  can  be  instructed  to  send 
Action  or  Info  copies  to  certain  users  if  certain  Keywords  are  found.  A reasonable 
default  would  be  to  ser.d  Info  copies  to  all  users  named  on  all  lists  associated  with 
matched  Keywords,  but,  since  action  is  usually  sent  to  one  user,  to  use  a first-match  or 
majority-match  algorithm  to  determine  the  recipient  of  the  Action  copy.  A more 
advanced  version  of  the  message  service  would  allow  arbitrary  Boolean  expressions  as 
the  routing  criteria. 

The  specific  routing  algorithm  employed  also  depends  on  the  type  of  addressee: 
User-ID,  Title,  or  Organization.  Messages  addressed  to  a user  would  normally  not  be 
forwarded  unless  specifically  requested  by  the  user  or  unless  the  priority  of  the 
message  required  immediate  attention.  Title  addressees  are  usually  designated  for  one 
of  three  main  reasons: 

- The  sender  wishes  to  reach  the  holder  of  a particular  position,  regardless  of  the 
individual  filling  it  (e.g.,  communications  officer). 

- The  sender  does  not  Know  the  most  suitable  recipient,  so  addresses  th©  message  to 
the  section  title  high  enough  in  the  (assumed)  hierarchy  to  be  sure  of  including  the 
appropriate  recipient. 

- The  sender  wishes  to  officially  address  a prestigious  title  (to  underscore  the 
importance  of  a message),  even  though  the  message  will  be  handled  at  a lower  level. 

When  messages  are  addressed  to  a Title,  the  service  will  consult  a routing  table, 
which  is  either  unique  for  that  title,  shared  between  several  titles,  or  a default.  A 
normal  default  would  be  no  forwarding  performed  unless  for  priority  reasons. 

Organizations,  like  titles,  are  not  associated  with  specific  users,  and  would  also  have 
routing  performed  by  routing  tables.  The  main  difference  between  organization  and 
title  routing  is  that  the  routing  tables  for  an  organization  will  be  specified  by  a specific 
administrator,  whereas  the  current  holder  of  a title  will  be  responsibla  for  the  routing 
for  that  title. 
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An  optional  service  performed  during  delivery  will  be  referential  d.J  ’button.  This 
would  provide  information  copies  of  any  incoming  message  to  members  of  the 
distribution  lists  of  any  previous  messages  referenced  in  the  incoming  message. 

Recaption 

Reception  is  the  phase  during  which  a user  categorizes,  acts  upon,  and  determines 
the  eventual  disposition  of  his  messages.  Each  of  the  above  actions  will  be  discussed 
individually. 

Manage  Categorization.  As  described  above  in  Delivery,  incoming  messages  are 
added  to  the  incoming  message  list  of  each  user,  in  addition,  each  user  is  notified  of 
messages  pending  for  all  titles  for  which  he  is  responsible.  The  user  may  specify 
whether  he  wishes  to  process  messages  sent  to  him  personally,  or  to  a title  within  his 
responsibility.  Each  user  chooses  how  these  messages  are  to  be  further  processed  for 
his  maximum  effectiveness.  Although  each  user  is  best  equipped  to  determine  what  is 
optimal  for  him,  the  primary  tools  he  can  use  are  content  folders,  sorting,  and 
abstracting. 

A user  can  determine  classes  of  messages  in  which  he  is  interested,  and  instruct  the 
service  to  append  incoming  messages  which  fall  into  these  classes  into  groups  called 
folders.  The  criteria  will  be  the  content  of  fields  of  interest  to  the  user.  Examples  of 
such  criteria  are  contents  of  Subject,  Body,  From,  Priority,  and  Security  fields,  and 
whether  the  user  is  in  the  Action,  Info,  or  Distribution  list  Of  a message.  When  matches 
to  user-specified  keywords  are  found,  the  service  places  the  message  in  the 
appropriate  folder,  with  the  user  deciding  the  folder  in  case  of  conflict  or  duplication  of 
keyword  matches,  or  failure  to  match.  These  actions  are  performed  for  the  user  when 
he  logs  on  to  the  service,  and  he  can  choose  to  be  informed  at  log-in  of  the  status  of 
any  or  all  of  his  folders,  and  any  new  messages  received  since  his  last  transaction  with 
the  service.  During  the  time  he  is  active  on  the  service,  he  can  choore  how  (or  if)  he  is 
to  be  notified  when  messages  are  received  while  he  is  active. 


A user  can  examine  any  fields  of  messages  in  any  of  h.s  folders,  on  the  basis  of 
which  he  may  change  folder  assignments.  He  may  also  designate  off-line  folders,  the 
contents  of  which  will  be  placed  in  the  user’s  personal  archive  after  a specified  interval. 

1 


In  addition  to  the  capabilities  provided  above  in  folders,  the  message  service  will 
also  provide  the  user  the  ability  to  sort  his  messages  independent  of  folder 
assignments.  Useful  examples  of  desirable  sorting  criteria  are  date  of  reception, 
alphabetical  by  From  field,  and  decreasing  priority.  The  sort  capability  will  provide 
additional  flexibility  that  might  not  be  easily  available  with  content-folders. 
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Users  will  also  need  methods  to  scan  quickly  through  their  messages  in  order  to 
determine  their  content  and  importance.  This  is  provided  by  the  abstracting  facility. 
Using  criteria  specified  by  the  user,  the  service  can  display  selected  fields  or  part  of 
fields,  pick  out  key  words  in  context,  and  provide  indices.  This  facility  will  allow  the 
user  to  process  larger  volumes  of  message  traffic  effectively. 

Action.  When  an  action  officer  is  assigned  the  action  on  a particular  message,  he 
is  expected  to  do  one  of  three  things:  act  immediately,  transfer  the  action,  or  suspend 
the  action.  He  is  not  expected  to  ignore  an  action  message,  though  the  service  cannot 
force  him  to  look  at  it. 

Immediate  Action 

If  the  action  officer  chooses  to  act  immediately,  he  may  compose  an  answering 
message  which  refers  to  the  original  action  message.  This  will  cause  the  service  to 
put  an  indication  into  the  original  action  message’s  status  file  saying  words  to  the 
effect  "action  taken  and  recorded  in  QA.CB/JUN  7,1974/  10:45:11  from  Major  Gross." 
If  the  action  reau'red  is  totally  outside  the  service,  the  action  officer  might  just 
inform  the  service  that  the  proper  action  has  been  taken.  In  this  case  the  status 
file  indication  would  be  more  like  "action  taken  by  Major  Gross  of  QAFB  on  JUN 
7,1974  10:45."  In  either  immediate  action  situation  the  message  is  removed  from  the 
action  officer’s  action  folder. 

Transferring  the  Action 

This  is  a case  where  the  action  officer  feels  that  a different  action  officer  should  be 
assigned  action  on  a particular  message.  He  notifies  the  service  of  this,  which  then 
informs  the  other  action  officer.  If  the  second  officer  agrees,  the  transfer  will  be 
made,  and  an  indication  will  be  placed  in  the  status  fils  recording  this  transfer 
("selling")  of  the  aci.on. 

Suspending  the  Action 

If  the  action  officer  wishes,  he  may  suspend  the  action  on  a particular  action 
message.  He  does  this  by  informing  the  service  when  he  expects  to  have  taken 
action  on  the  message.  He  should  also  tell  the  system  if  and  when  he  wishes  the 
service  to  remind  him  of  this  suspended  task.  In  addition  to  the  indication  in  the 
status  file  ("action  suspended  ..."),  this  message  will  be  placed  in  the  action  officer’s 
suspense  file.  The  suspense  file  is  used  by  the  service  to  generate  schedules  and 
reminders  to  the  action  officers. 


Information,  Distribution,  etc.  If  the  message  recipient  is  not  the  action  officer 
for  the  message  in  question,  than  his  responsibility  with  respect  to  the  message  is  not 
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as  dear  as  above.  The  copy  has  basically  been  sent  for  the  recipient’s  information. 
He  has  many  options  with  regard  to  these  information  messages.  They  break  down  into 
four  classes:  destroy,  distribute,  keep  off-line,  keep  on-line. 

Destroy 

If  the  action  officer  wants  no  more  to  do  with  a message,  he  may  delete  it  from  his 
purview.  If  it  is  a formal  message,  there  will  always  be  an  archive  copy.  In  the 
informal  case,  other  recipients  might  have  copies.  Other  variations  on  this  theme 
involve  removing  message  copies  from  one  message  folder,  but  leaving  copies  in 
other  folders. 

Distribute 

If  the  action  officer  wishes  and  the  Special  handling  field  allows,  he  may  request  the 
service  to  forward  copies  of  the  message  to  others.  This  would  cause  a indication 
in  the  status  file  to  the  effect  "Major  Jones  forwarded  message  to  x,y,  and  z on  JUN 
i.  variation  here  includes  a joint  forward  and  delete  operation,  wh:ch  is  very 
similiar  to  selling  the  action  as  described  above.  However,  the  interaction  in  this 
case  is  much  simpler  as  no  one  is  considered  to  be  in  a position  to  refuse 
information. 

Keep  Off-line 

If  the  recipient  and  the  Special  handling  agree,  the  service  will  generate  a hardcopy 
of  the  message. 

Keep  On-line 

The  action  officer  can  move  the  message  from  some  to-be-processed  (suspense) 
foider  to  a record-keeping  folder.  Messages  may  be  kept  for  a long  period  of  time 
in  user  folders.  Actually,  if  a message  is  not  accessed  in  some  period  the  folder 
entry  will  be  reduced  from  the  message  to  just  a Message-ID  into  the  archive.  Any 
informal  message  which  is  not  in  a folder  of  some  user  is  purged  from  the  service. 
Any  formal  message  which  is  not  in  a folder  of  some  user  and  is  older  than  a given 
age  (defined  by  each  installation)  is  purged  from  the  archive. 

The  status  file  for  each  transmitted  message  is  maintained  by  the  service  and 
readily  accessible  to  each  person  related  to  the  message.  When  a message  is  finally 
settled,  the  status  file  is  approp-iately  pruned  and  merged  with  the  archive  message 
copy.  In  summary,  the  receiver  can  have  his  incoming  traffic  sorted,  then  he  can  take 
the  appropriate  action  relative  to  action  messages  or  information  messages.  Finally  he 
disposes  of  the  message  and  it  moves  to  the  archive.  During  this  entire  process  the 
service  is  maintaining  status  information  on  the  message  to  enable  other  parties  to  track 
its  progress. 
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Archival 

Archival  occurs  at  the  origin  and  destination  sites  for  all  formal  message  traffic. 
The  procedures  will  be  straightforward,  providing  off-line  retention  of  all  messages  for 
a specified  period.  [A  more  advanced  message  service  will  provide  an  cn-line  index  to 
relevant  fields  of  all  archived  messages,  to  provide  quick  reference  to  past  formal 
traffic.] 

Figure  1 is  an  example  of  the  possible  printout  of  message  CAFB / Jun  17,1974/ 
10:55:17  as  retrieved  from  the  archive.  This  is  to  show  what  information  is  kept  with 
an  archived  message. 


ADMINISTRATIVE  FUNCTIONS 

In  addition  to  the  user  capabilities  described  above,  the  service  will  provide  several 
administrative  functions  as  well.  These  will  be  primarily  record-keeping  services,  such 
as  type  and  volume  of  message  traffic,  service  utilization,  archive  status,  etc.  Privileged 
administrators  will  also  be  allowed  to  set  service  parameters,  add  or  delete  users,  and 
perform  necessary  housekeeping  operations.  As  the  nature  of  these  services  is  highly 
installation-dependent,  detailed  specification  will  be  deferred  until  user  requirements 
are  known. 
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Message  Type: 
Transmit  ID: 

Create  ID: 
References: 

From: 

By: 

Security: 

Action  List: 

Info  List: 

Distribution: 

Coordination: 

Release: 

Subject: 

Body: 


Formal 

QAFB/JUN  17,1974/10:55:17  from  General  Smith 

QAFB/JUN  17,1974/7:13:11  by  Major  Jones 

XAFB/APR  12,1974/11:21:17  from  Logistics 
YAFB/MAY  11,1974/15:13:11  by  Logistics 
ZAFB/JAN  5,1974/17:34:16  by  Logistics 

General  Smith  of  QAFB  [OK  final] 

Major  Jones 

SECRET 


All  Immediate  Priority: 

Logistics  at  XAFB,  Logistics  at  YAFB, 
Logistics  at  ZAFB. 

All  Routine  Priority: 

Commander  at  XAFB,  Commander  at  YAFB, 
Commander  at  ZAFB. 


Capt.  Green, 


Capt.  Black 


Capt.  Alpha 
Capt.  Beta 
Capt.  Gamma 
Major  Hart 


Read  Preliminary 
NG  Preliminary 
OK  Final 
OK  Final 


Major  Heart 
Major  Hart 
Major  Harte 


OK  Preliminary 
OK  Final 
OK  Final 


Shortage  of  bearings  at  QAFB 

If  you  can  please  ship  10,000  type  QRST  bearings  immediately, 
we  would  appreciate  it  m .'chly. 


Figure  1.  An  example  of  an  archival  message 
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APPENDIX 


Oiscussions  with  representatives  of  an  eventual  COTCO  user  group  have  identified 
tome  additional  needs  and  constraints  to  be  incorporated  into  the  COTCO  Military 
Message  Service.  These  modifications,  which  alter  or  limit  the  specifications  of  the 
service  as  presented,  are  specified  below. 

The  COTCO  community  has  expressed  concern  that  the  message  service  be 
implemented  as  basically  and  simply  as  possible.  It  is  thought  that  a multitude  of 
available  options  and  capabilities  may  hamper  effectiveness  by  1)  confusing  the  novice 
user  with  a host  of  unfamiliar  choices,  2)  providing  a more  Knowledgeable  user  with 
unnecessary  options,  and  3)  degrading  response  time  with  additional  processing  of 
increased  services. 

The  various  modules  of  the  User’s  Agent  (part  of  the  message  service)  have  in  fact 
been  designed  to  cope  with  precisely  the  above  considerations.  By  maintaining  a 
profile  for  each  user,  the  service  can  tailor  its  appearance  to  each  user  to  be  consistent 
with  that  user's  expertise.  The  ubiquitous  presence  of  a help/tutor  facility  provides 
the  user  with  information  and/or  instruction  where  he  is  ursure  of  what  to  do  or  what 
he  has  done,  and  the  existence  of  an  ’’experimental''  mode  and  a universal  ’’undo” 
function  attempts  to  insulate  the  user  from  the  effects  of  potentially  damaging  errors. 
In  addition,  the  real-time  monitoring  modules  of  the  service  attempt  at  all  times  to 
provide  smooth,  consistent  response  from  the  service. 

The  desired  consequence  of  these  facilities  will  be  to  provide  a service  which,  while 
powerful,  will  present  its  capabilities  in  a natural,  expandable  form,  at  each  user’s  own 
pace.  Therefore,  restrictions  to  the  capabilities  of  the  message  service  should  be  made 
on  ti  e basis  of  inessentiality  or  inapplicability,  rather  than  the  concern  that  .ocreased 
power  must  be  paid  for  by  impaired  user  performance. 

In  light  of  the  above  considerations,  some  capabilities  of  the  message  service  were 
deemed  unnecessary  for  COTCO  requirements.  These  consisted  primarily  of  restriction 
of  alternatives  where  the  increased  number  of  choices  would  not  provide  more 
meaningful  information  for  the  users.  These  include: 

1)  The  release  list  is  not  needed,  as  the  forma:  sender  (From)  constitutes  the  single 
releasing  authority  for  a given  message.  All  other  reviewing  needs  are  satisfied  by 
designating  other  users  as  coordinators. 
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2)  The  only  signoff  codes  required  are  “OX*  and  "NG,“  since  more  '•odes  would  only 
encourage  quibbling,  rather  than  provide  flexibility. 

3)  A question  was  raised  as  to  the  very  general  ghost  structure  and  whether  such 
generality  was  required.  It  is  felt  that  the  ghost  issue  is  not  yet  well-understood 
enough  to  make  a definitive  decision  on  whether  (and  how)  it  should  be  restricted. 

The  remainder  of  the  COTCO  requirements  deal  with  minor  tuning  of  existing 

capabilities.  The  affected  areas  are  listed  below: 

1)  In  the  COTCO  environment,  the  formal  sender  of  a message  (From)  must  have  the 
ability  to  modify  a draft  message  and  control  its  progress,  in  the  same  way  that  an 
author  car.  Thus,  the  sending  authority  will  have  full  author  rights:  he  can  crpate 
and  modify  a message,  route  it  for  coordination  (or  recall  it),  and  .ransmit  the 
message  at  his  discretion.  The  author  ana  releaser  share  the  responsibility  for  the 
preparation  phases  of  a message. 

2)  COTCO  would  find  it  useful  to  further  delineate  distinctions  between  formal  and 
informal  messages.  The  following  chart  lists  the  currently  desirable  distinctions: 


FORMAL 

INFORMAL 

From  field  is  a t'tle 

From  field  is  a name 

Releasers  limited  to 
restricted  subset  of 
users 

May  be  released  by  any 
user 

Subject  to  incoming 
routing  procedures 

Never  routed  unless 
directed  specifically 
by  recipient 

May  be  any  priority 

May  be  Routine  priority 
only 

Placed  in  permanent 
message  archive 

Not  saved  except  by 
individual  users 

IP 

i 
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In  addition,  COTCO  would  like  to  see  coma  immediately  recognizable  phytical 
distinction  between  formal  and  informal  messages.  Suggestions  tor  such  distinctions 
include:  displaying  the  messages  in  different  fonts,  or  black  o*  white  versus  white  on 
black. 

COTCO  expressed  a desir*  for  transaction  iogs  and  administrative  facilities,  but  as 
yet  the  specifics  of  such  requirements  ri  vague.  Further  interaction  with  the 
end*users  and  administrative  officials  will  define  those  needs. 
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